Kubernetes Authentication with Okta OIDC

Replacing certificate-based auth with centralized identity — no more manual cert generation

In a previous post I covered Kubernetes RBAC from scratch — creating users with certificates, binding them to groups, and storing credentials in Vault. That approach works but it has friction: every new user needs a cert generated, a CSR submitted, approved, and distributed. It doesn’t scale and there’s no central place to revoke access instantly.

This post picks up where that one left off. The RBAC configuration stays exactly the same — ClusterRoles, ClusterRoleBindings, group-based permissions — but authentication moves to Okta via OIDC. Users log in with their existing Okta credentials and their group membership in Okta drives what they can do in the cluster.

How It Works

Kubernetes doesn’t manage users itself — it delegates authentication to external systems. OIDC is one of those systems. When a user runs kubectl, a plugin called kubelogin handles the browser-based login flow with Okta and returns a signed JWT token. kubectl passes that token to the API server, which validates it against Okta’s public keys and reads the claims to determine who the user is and what groups they belong to.

User runs kubectl
       │
       ▼
kubelogin (exec credential in kubeconfig)
       │
       ▼
Browser opens → Okta login page
       │
       ▼
User authenticates (password + MFA)
       │
       ▼
Okta issues JWT token:
  sub: unique user ID
  groups: ["naxslabs-admins"]
       │
       ▼
kubectl sends request to API server with token
       │
       ▼
API server validates token → reads groups claim
→ matches ClusterRoleBinding → request allowed or denied

Okta App Setup

Create a new app in Okta for the Kubernetes cluster.

Applications → Create App Integration:

• Sign-in method: OIDC – OpenID Connect
• Application type: Native Application

Grant types: Authorization Code only. Enable Require PKCE. Set Client Authentication to None.

Sign-in redirect URI:

http://localhost:8000

This is where kubelogin spins up a local server to catch the token after Okta redirects back. It’s HTTP but only ever listens on loopback — the token never travels over an unencrypted network connection.

Assignments: Limit access to your admin group — don’t leave this open to everyone in the org.

Configure the Groups Claim

Okta doesn’t include group membership in tokens by default. You have to explicitly add it.

Security → API → Authorization Servers → default → Claims → Add Claim:

Authorization Server Access Policy

The groups claim and the app assignment aren’t enough on their own. The Okta authorization server has its own access policy that must also allow the request. Without this you’ll get a no_matching_policy error in the Okta system log even though everything else looks correct.

Security → API → Authorization Servers → default → Access Policies → Add Policy: assign it to your K8S app, add a rule allowing your group with Authorization Code grant type.

Installing kubelogin

# Via krew
kubectl krew install oidc-login

# Or direct binary
curl -LO https://github.com/int128/kubelogin/releases/latest/download/kubelogin_linux_amd64.zip
unzip kubelogin_linux_amd64.zip
mv kubelogin /usr/local/bin/kubectl-oidc_login

Test the Token Before Touching the API Server

Before making any changes to the cluster, verify the Okta flow works and check what’s in the token:

kubectl oidc-login setup \
  --oidc-issuer-url=https://your-okta-domain/oauth2/default \
  --oidc-client-id=your-client-id \
  --listen-address=localhost:8000

This opens a browser, completes the login, and prints the decoded token. Verify the groups claim is present and contains the right groups before proceeding. If it’s missing, the Okta claim configuration needs fixing first.

Configuring the Kubernetes API Server

The API server needs to know where to validate tokens. Edit the static pod manifest on each control plane node — kube-apiserver is a static pod managed locally on each node, not a cluster-wide resource, so this can’t be done with kubectl.

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Find the command: section and add these four flags:

- --oidc-issuer-url=https://auth.yourdomain.com/oauth2/default
- --oidc-client-id=your-client-id
- --oidc-username-claim=sub
- --oidc-groups-claim=groups

The API server restarts automatically when the manifest is saved. Give it about a minute then verify the flags loaded:

ps aux | grep kube-apiserver | grep oidc

Configuring kubeconfig

kubectl config set-credentials oidc \
  --exec-api-version=client.authentication.k8s.io/v1 \
  --exec-command=kubectl \
  --exec-arg=oidc-login \
  --exec-arg=get-token \
  --exec-arg="--oidc-issuer-url=https://auth.yourdomain.com/oauth2/default" \
  --exec-arg="--oidc-client-id=your-client-id" \
  --exec-arg="--listen-address=localhost:8000" \
  --exec-interactive-mode=IfAvailable

kubectl config set-context oidc \
  --cluster=kubernetes \
  --user=oidc \
  --namespace=default

kubectl config use-context oidc

After switching context, the next kubectl command automatically triggers the browser login. The token is cached so subsequent commands don’t re-prompt until it expires (controlled by Okta token lifetime, default 1 hour).

RBAC — Nothing Changes

The ClusterRoles and ClusterRoleBindings from the previous post work unchanged. The only difference is group membership now comes from Okta instead of the cert O field. A binding like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: your-group-binding
subjects:
- kind: Group
  name: naxslabs-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin-role
  apiGroup: rbac.authorization.k8s.io

Works because Okta puts naxslabs-admins in the token’s groups claim, the API server reads it, and matches it against this binding. No changes to RBAC needed when switching from cert auth to OIDC.

Onboarding New Users

Store the kubeconfig in Vault and users pull it themselves:

# Admin stores it
vault kv put secret/kubernetes/kubeconfig config=@~/.kube/config

# User pulls it
vault kv get -field=config secret/kubernetes/kubeconfig > ~/.kube/config
kubectl config use-context oidc
kubectl get pods   # browser login, done

Authentication and Session Policies Still Apply

Getting OIDC working is only part of the picture. Okta’s authentication policies and session policies still govern how users prove their identity before a token is ever issued — and they apply to every app including your Kubernetes integration.

Things to consider for your Kubernetes app specifically:

• MFA requirements — decide whether password alone is sufficient or whether a second factor (Okta Verify, WebAuthn, TOTP) is required for cluster access
• Re-authentication frequency — Okta can require re-auth every session, or allow a longer window. For cluster access you likely want this tighter than a general SaaS app
• Network zone restrictions — consider limiting cluster authentication to known IP ranges or VPN if your cluster isn’t public-facing
• Device trust — if you have Okta Verify with device trust configured, you can require a managed or trusted device before issuing tokens

Troubleshooting

Key Takeaways