As a lot of curious people, I have experimented with ChatGPT in order to figure out if it could be helpful in my work as a DevOps consultant or even replace me (why not?). If you are also interested to see how ChatGPT compares with an Oracle DBA, you can check the very interesting blog of my colleague that did that assessment.

First I have to say that I was pleasantly surprised by the accuracy of the responses to basic questions regarding DevOps technology like Ansible, Kubernetes, Rook Ceph, Docker, GitLab… ChatGPT keeps the context of a chat so I usually start by asking general questions as Do you know Kubernetes? where I got a general but accurate response and from there I ask for more details about a component, a script or a command. Each time the response is quite accurate and you can challenge ChatGPT when you test a command and it doesn’t work, he is able to recognized he was wrong!

First contact

My first feeling is that ChatGPT is a great interactive encyclopedia on which you can quickly get information by asking questions and the intelligence I see is that it understands the questions quite well, provides accurate answers and keeps the context of the conversion in order to elaborate or give details and even correct itself. Of course you have to guide the responses by asking the right questions but for learning and to get you started I think it’s great as you can quickly gather information about a technology. In that sense it was faster than doing some research with a traditional search engine. However the drawback is that you get answers from a single source of truth and you lack the diversity of answers you get from various blogs and websites when you do an usual research on the Internet. So you will have to test those answers, cross check them and challenge ChatGPT a for better answer as it will also learn from you (don’t forget that if it’s free, you are the product!).

I’ve previously blogged about Kubernetes SSO using Azure AD and I was curious to know if ChatGPT could have helped me to find the same solution, another one or just found one quicker. Let’s have a look what ChatGPT has in store about it!

ChatGPT vs Kubernetes SSO using Azure AD

What are the steps to implement SSO in Kubernetes with Azure?

  1. Create an Azure Active Directory (AAD) tenant and register your application in the tenant.
  2. Create a Service Principal for the registered application and assign necessary permissions.
  3. Configure AAD as the identity provider in Kubernetes using the AAD integration in Kubernetes.
  4. Use the Service Principal credentials to authenticate to the Kubernetes cluster.
  5. Configure Role-based Access Control (RBAC) in Kubernetes to grant access to users and groups in AAD.
  6. Test SSO by logging in to the Kubernetes cluster using AAD credentials.

Note:

  • The above steps are high level steps and there can be more details and steps involved depending on your use case.
  • Also, you might need some Azure Kubernetes Service (AKS) related configurations as well.

The first response is already a good summary and the last note informs us that those are only high level steps. However the mention to AKS is not relevant here but he couldn’t have known as in my question I didn’t specify OnPrem Kubernetes or Azure Kubernetes.

Could you detail how to configure SSO in Kubernetes?

  1. Create an Azure Active Directory (AAD) tenant if you do not have one already.
  2. Register your application in the tenant by going to the Azure portal, selecting Azure Active Directory, and then selecting App registrations.
  3. Create a Service Principal for the registered application and assign necessary permissions by going to the Azure portal, selecting Azure Active Directory, and then selecting App registrations.
  4. Configure AAD as the identity provider in Kubernetes by using the AAD integration in Kubernetes. This can be done by modifying the kube-apiserver manifest to include the –oidc-issuer-url, –oidc-client-id and –oidc-ca-file flags and pointing them to the AAD tenant.
  5. Use the Service Principal credentials to authenticate to the Kubernetes cluster by passing them as environment variables to the kubelet.
  6. Configure Role-based Access Control (RBAC) in Kubernetes to grant access to users and groups in AAD. This can be done by creating roles and role bindings in Kubernetes that map to users and groups in AAD.
  7. Test SSO by logging in to the Kubernetes cluster using AAD credentials by running kubectl commands with the –token option and providing a valid AAD token.

Step 4 for configuring kube-apiserver is added and ChatGPT gives a bit more details in the other steps in comparaison to my first question. This is all correct and quite good.

Could you show an example of kube-apiserver manifest?

Here’s an example of a kube-apiserver manifest that includes the configuration for SSO using Azure Active Directory:

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  labels:
    component: kube-apiserver
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver:v1.19.0
    command:
    - kube-apiserver
    - --oidc-issuer-url=https://sts.windows.net/<AAD tenant ID>/
    - --oidc-client-id=<client ID>
    - --oidc-ca-file=/etc/kubernetes/pki/ca.crt
    - --oidc-username-claim=email
    - --oidc-groups-claim=groups
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --enable-admission-plugins=Initializers,NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota
    - --authorization-mode=RBAC
    - --etcd-servers=https://etcd-0.etcd:2379,https://etcd-1.etcd:2379,https://etcd-2.etcd:2379
    - --advertise-address=1.2.3.4
    - --bind-address=0.0.0.0
    - --secure-port=6443
    volumeMounts:
    - name: ca-certs
      mountPath: /etc/kubernetes/pki
  volumes:
  - name: ca-certs
    configMap:
      name: kubernetes-pki

You can see that the kube-apiserver container is configured with the --oidc-issuer-url, --oidc-client-id, and --oidc-ca-file flags, which point to the AAD tenant and client ID, and the certificate authority file for the AAD tenant, respectively. The --oidc-username-claim and --oidc-groups-claim flags are used to map AAD user’s claims to the corresponding Kubernetes user and group.

Please note that this is just an example and your actual kube-apiserver manifest may differ depending on your specific environment.

Also, you need to pass the --token option with a valid AAD token to kubectl command, in order to authenticate to the cluster

Not bad at all! ChatGPT generates an example of a kube-apiserver.yaml file and explains each parameters related to our SSO discussion. Let’s push a bit further:

Could you give also an example of .kube/config file to use with this kube-apiserver?

Here’s an example of a .kube/config file that can be used to authenticate to a Kubernetes cluster with SSO using Azure Active Directory:

apiVersion: v1
kind: Config
clusters:
- name: my-cluster
  cluster:
    server: https://kubernetes.default.svc
    certificate-authority-data: <base64 encoded CA data>
    insecure-skip-tls-verify: true
  users:
- name: azure-user
  user:
    auth-provider:
      name: azure
      config:
        tenant-id: <tenant id>
        client-id: <client id>
        client-secret: <client secret>
        idp-issuer-url: https://sts.windows.net/<tenant id>/
        idp-certificate-authority-data: <base64 encoded CA data>
        idp-audience: https://kubernetes.default.svc
contexts:
- name: my-context
  context:
    cluster: my-cluster
    user: azure-user
current-context: my-context

The above .kube/config file defines a cluster named my-cluster and an user named azure-user. The auth-provider field for the azure-user is set to azure and the config field contains the necessary configuration for authenticating to AAD. The configuration includes the tenant ID, client ID, client secret, and the URL of the AAD tenant. It also includes the CA certificate data for the AAD tenant and the expected audience for the token.

You also need to set the current context as my-context in order to use this configuration file.

Please note that this is just an example and your actual .kube/config file may differ depending on your specific environment.

Not bad either! I like the note of warning at the end as well as the additional information about the context that I could dig deeper by asking specifically a question about it.

For those of you who have read my blog you will notice that the .kube/config file is using the parameters of the deprecated method. ChatGPT is working on data up to 2021 so he may suggest that well-known solution first. As I know this topic well now, I can try to guide him to the direction of the newest method and see what will come out.

Modify .kube/config configuration by using oidc-login plugin of kubectl

Here’s an example of a modified .kube/config file that can be used to authenticate to a Kubernetes cluster with SSO using Azure Active Directory and the oidc-login plugin of kubectl:

apiVersion: v1
kind: Config
clusters:
- name: my-cluster
  cluster:
    server: https://kubernetes.default.svc
    certificate-authority-data: <base64 encoded CA data>
    insecure-skip-tls-verify: true
users:
- name: azure-user
  user:
    exec:
      command: oidc-login
      args:
      - --issuer-url=https://sts.windows.net/<tenant id>/
      - --client-id=<client id>
      - --username-claim=email
      - --groups-claim=groups
      - --ca-file=path/to/ca.crt
      - --extra-scopes=openid,email,groups
      - --extra-audiences=https://kubernetes.default.svc
contexts:
- name: my-context
  context:
    cluster: my-cluster
    user: azure-user
current-context: my-context

The above .kube/config file defines a cluster named my-cluster and an user named azure-user. The exec field for the azure-user is set to oidc-login and the args field contains the necessary configuration for authenticating to AAD with the plugin. The configuration includes the issuer URL, client ID, username claim, groups claim, and ca file. Additionally, you can set extra scopes and audiences as well.

When you run kubectl commands with this config, the plugin will automatically launch an OIDC flow and obtain an access token for the user.

Please note that this is just an example and your actual .kube/config file may differ depending on your specific environment and the plugin version you use.

So ChatGPT knows this solution as well as is able to provide the required parameters. To reach that point I needed some knowledge myself in order to ask the question properly but anyway we can see that quickly we have the basis on which we can get started.

ChatGPT Limits

If you’ve read my blogs (Part 1 and Part 2) about SSO, you know that we were looking for a solution to connect the oidc plugin with HTTPS to Azure that supports only this protocol. Let’s see if ChatGPT could have found a solution quicker than us:

Adjust oidc-login plugin azure-user to use https

Here’s an example of how you can modify the azure-user configuration in the .kube/config file to use HTTPS with the oidc-login plugin:

apiVersion: v1
kind: Config
clusters:
- name: my-cluster
  cluster:
    server: https://kubernetes.default.svc
    certificate-authority-data: <base64 encoded CA data>
users:
- name: azure-user
  user:
    exec:
      command: oidc-login
      args:
      - --issuer-url=https://sts.windows.net/<tenant id>/
      - --client-id=<client id>
      - --username-claim=email
      - --groups-claim=groups
      - --ca-file=path/to/ca.crt
      - --extra-scopes=openid,email,groups
      - --extra-audiences=https://kubernetes.default.svc
      - --https
contexts:
- name: my-context
  context:
    cluster: my-cluster
    user: azure-user
current-context: my-context

The above .kube/config file defines a cluster named my-cluster and an user named azure-user. The exec field for the azure-user is set to oidc-login and the args field contains the necessary configuration for authenticating to AAD with the plugin. In the args field --https is added to make the plugin use https for redirects and token exchange

When you run kubectl commands with this config, the plugin will automatically launch an OIDC flow and obtain an access token for the user over HTTPS.

Please note that this is just an example and your actual .kube/config file may differ depending on your specific environment and the plugin version you use.

Well that’s interesting because the –https parameter just doesn’t exist so let’s challenge that neuronal beast:

–https doesn’t work

I apologize for any confusion, you are correct that the --https flag is not a valid option for the oidc-login plugin. It seems that this flag was included in my previous response by mistake.

To use HTTPS with the oidc-login plugin, you can configure it to use a reverse proxy that supports HTTPS and set the issuer-url and redirect-url accordingly. Additionally, you can ensure that the ca-file option points to a valid CA certificate.

It is also good to configure the endpoints in your Azure Active Directory tenant to use the https protocol.

I apologize for any confusion caused by my previous response, please let me know if you have any other questions.

Very polite indeed, I guess this is where ChatGPT is learning from his mistakes. He then points us to the direction of a reverse proxy but not to the parameters I was looking for (–local-server-cert and –local-server-key).

I’ve continued to ask for other solutions and other parameters to see if he knew them but he was running in a loop by suggesting other parameters that don’t exist. So I’ve finally given him the solution I was looking for:

What about the –local-server-cert and –local-server-key parameters?

I apologize for my previous errors, you are correct that oidc-login plugin supports https by using --local-server-cert and --local-server-key parameters. --local-server-cert allows you to specify the location of the certificate file that should be used to establish an HTTPS connection with the OIDC provider. --local-server-key allows you to specify the location of the private key file that should be used to establish an HTTPS connection with the OIDC provider.

OK! So in this case he was confirming I was correct (call me BenGPT). As you can see, after a certain depth from the basic core topic, you reach the limit of ChatGPT…for now at least.

Conclusion

I come to the same conclusion as my colleague regarding Oracle DBA, ChatGPT will not replace a DevOps consultant yet as we can reach its limits when the topic becomes too complex or when we need a creative solution to an issue. In the first part of my SSO Blog, I needed to troubleshooting a secret parameter with or without ” ” and I think this could not have been found by ChatGPT at this stage.

However it has been announced that ChatGPT will be updated and will become much more powerful so we can expect that it will greatly improve and expand its limits. I will continue to use it as I am still amazed by its capacities to summarize information about a topic and can greatly help to get started on any topic I need to learn as a DevOps consultant. ChatGPT is just the beginning of a new era with AI and I see it as taking more and more importance in our daily work not as a replacement but as a valuable assistant.