Connect clusters via OIDC client credetials flow

[jobo-prod]

I was wondering if it is supported/possible to authenticate ArgoCD to external clusters via generic OIDC (client credentials flow). For clusters using OIDC authentication, this is (if I'm not mistaken)

• easy to implement: no certificate/secret rotation and automation needed
• scalable: requires only a single argocd serviceaccount in the ID provider and one user:argocd -> clusterrole:cluster-admin binding per target cluster
• secure: no long-lived Kubernetes serviceaccount tokens with admin privileges lingering in the infrastructure

There is a command called argocd-k8s-auth and also a execProviderConfig struct in the cluster configuration, but only little documentation about it (it just mentions some traditional cloud providers). Can I leverage those for this use case or is there another way?

Thanks in advance and cheers!

[jobo-prod]

I found out: It is possible using the execProviderConfig struct. There, a command must be specified which returns an ExecCredential struct (see Kubernetes docs for details) to stdout. This can be achieved by kubelogin a.k.a. kubectl oidc-login, the standard plugin for OIDC authentication:

1. In your OIDC provider, add a service account for the ArgoCD client and if required, grant it any permissions for accessing Kubernetes. If you're not already using OIDC login for the ArgoCD UI, create a confidential client first and store the client secret in a Kubernetes secret for ArgoCD. This is ArgoCD's credential for acquiring ID tokens for Kubernetes access.
2. For for argocd-server and argocd-application-controller add the kubelogin binary to the container image using an image volume or a custom image. Also add ENVs and/or volume mounts containing the client ID and client secret.
3. Add a cluster secret similar to the following config:

   {
     "tlsClientConfig": {
       "insecure": false,
       "caData": "<cluster ca in base64>"
     },
     "execProviderConfig": {
       "apiVersion": "client.authentication.k8s.io/v1",
       "command": "sh",
       "args": ["-c", "stat /var/run/secrets/oidc/clientSecret > /dev/null && kubelogin get-token --oidc-issuer-url=https://auth.example.org/realms/foo --oidc-client-id=kubernetes --grant-type=client-credentials --oidc-request-header=\"Authorization=Basic $(echo -n \"$OIDC_CLIENT_ID:$(cat /var/run/secrets/oidc/clientSecret)\" | base64 -w0)\""],
       "provideClusterInfo": false
     }
   }

   ArgoCD will use this command to acquire an ID token for authenticating to the desired cluster from your ID provider. This implements the "client credentials flow". The return value also contains a timestamp for the token validity, so ArgoCD will automatically issue a new token when required.
4. On the cluster side, a single ClusterRoleBinding is sufficient, granting ArgoCD admin privileges:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: argocd-oidc
   subjects:
     - apiGroup: rbac.authorization.k8s.io
       kind: User
       name: https://auth.example.org/realms/foo#service-account-argocd # depends on your OIDC configuration and provider
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: cluster-admin

   The exact username depends on your OIDC configuration in Kubernetes and in the provider. You can find out with kubectl auth whoami using an ID token for ArgoCD.

The above example assumes the ArgoCD client ID in variable $OIDC_CLIENT_ID and client secret mounted to /var/run/secrets/oidc/clientSecret. It transforms them into a basic auth header on the fly by adding some shell sugar. You could also directly provide the header value and avoid wrapping the kubelogin command into sh.