kubernetessecurityPractitioner

Kubernetes Access via Public Clients: Mastering OIDC with PKCE

5 min read CNCF BlogSep 8, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Kubernetes access management is critical for maintaining security and efficiency in your clusters. By integrating with an identity provider using a public client, you can enhance your authentication process without the need for a client secret. This setup is particularly useful in scenarios where you want to avoid exposing sensitive information while still ensuring secure access to your Kubernetes resources.

The mechanism involves three key components: kubectl, your identity provider (like Keycloak), and kube-apiserver. Kubectl initiates the login process using the kubelogin exec plugin, which retrieves a token from the identity provider. This token contains essential user information, such as username and group membership. Kube-apiserver then validates this token and uses Role-Based Access Control (RBAC) to determine what actions the user can perform. For configuration, you'll need to set parameters like --oidc-issuer-url and --oidc-client-id to point to your identity provider and identify your client.

In production, be aware of common pitfalls. If you're using a self-hosted Keycloak instance, ensure its certificate is signed by a publicly trusted CA. If not, you'll need to specify the CA certificate using the --oidc-ca-file flag. This detail is crucial for avoiding authentication issues. Keep your Kubernetes version in mind, as this integration is continually evolving, and staying updated can save you from potential headaches.

Key takeaways

→Configure kubectl with the kubelogin exec plugin to streamline authentication.
→Use PKCE to enhance security by preventing interception of authorization codes.
→Validate user identity with RBAC based on the claims in the ID token.
→Specify the OIDC issuer URL and client ID for proper integration.
→Add the CA certificate flag if using a self-signed Keycloak certificate.

Why it matters

Implementing public clients with PKCE in Kubernetes significantly reduces the risk of credential exposure, enhancing overall cluster security. This method allows for seamless integration with identity providers while maintaining strict access controls.

Code examples

YAML

1apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRoleBinding
3 metadata:
4   name: platform-viewers
5 subjects:
6   - kind: Group
7  name: platform-viewer
8  apiGroup: rbac.authorization.k8s.io
9 roleRef:
10   kind: ClusterRole
11   name: view
12   apiGroup: rbac.authorization.k8s.io

YAML

1users:
2 - name: oidc
3   user:
4  exec:
5    apiVersion: client.authentication.k8s.io/v1
6    command: kubectl
7    args:
8      - oidc-login
9      - get-token
10      - --oidc-issuer-url=https://<your-keycloak-host>/realms/<realm>
11      - --oidc-client-id=kubernetes

Bash

$ kubectl auth whoami
ATTRIBUTE   VALUE
 Username	jane.doe@example.com
 Groups	[platform-viewer system:authenticated]

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

Kubernetes Access via Public Clients: Mastering OIDC with PKCE

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Mastering Vulnerability Reports in Open Source: A Kubernetes Perspective

KubeletInUserNamespace: Elevating Security in Kubernetes v1.37

Kubernetes v1.37: Mastering Pod Certificates and Cluster Trust Bundles