Abdelhalim El Jarzini
Design Networking & Security

Kubernetes cluster access: RBAC tiers with a path to single sign-on

A proposed access model for a cluster shared through one admin kubeconfig. Per-user identities come first and OIDC groups later, with roles that never need rewriting.

My role
Wrote the design, covering options, role tiers, namespace strategy, rollout and verification steps.
Context
Internal platform work at ITGS · 2026
Status
Proposed design, not implemented
Stack
  • Kubernetes RBAC
  • X.509 client certificates
  • OIDC
  • kubelogin
  • API audit logging
1 · Who: authentication
Now: per-user client certificatesCN = user · O = role group

Signed by the cluster CA; no extra infrastructure

Later: OIDC groupsSSO login with kubelogin

Central revocation by disabling the user

PipelinesServiceAccount tokens
2 · Bindings: the only part that changes
RoleBinding / ClusterRoleBindingsubject kind: Group

Certificate group today, OIDC group tomorrow

System namespaces stay admin-only: no operator or developer bindings there.
3 · What: authorization, stable
cluster-admin1–2 people
namespace-operatoredit in assigned app namespaces
developerown namespace, no Secrets or RBAC
viewerread-only, no Secrets
ci-deployernamespace edit, ServiceAccount
DesignProposed design, not implemented. Roles are written once; moving from certificates to single sign-on changes only the binding subjects.

The problem

The cluster built with the Talos runbook had a single credential: an admin client-certificate kubeconfig with full cluster-admin rights and a one-year certificate, shared by everyone who needed access. That means no individual accountability, no least privilege and no way to revoke one person without rotating access for everyone.

Options considered

OptionForAgainst
A. Per-user X.509 client certificates signed by the cluster CANo extra infrastructure, works today, standard kubectl flowManual issuance and revocation, no central directory
B. OIDC through an identity providerCentral identity, SSO, instant revocation by disabling the user, group-based rolesDepends on the identity-provider work being finished first
C. Static token file or webhookSimpleDiscouraged upstream, no rotation story. Rejected

Recommendation: start with A so RBAC is not blocked, but design the roles so that the binding subject is the only thing that changes when B arrives. A certificate’s O field becomes the Kubernetes group, so bindings already target groups rather than individuals, and the migration swaps certificate groups for OIDC groups without rewriting a single role.

Role tiers

RoleScope
cluster-adminWhole cluster. One or two people
namespace-operatorEdit workloads in assigned app namespaces, with no RBAC or secrets escalation
developerDeploy their own app in their namespace, with no access to Secrets, RBAC or other namespaces
viewerRead-only across the cluster, excluding Secrets
ci-deployerNamespace-scoped edit through a ServiceAccount, for pipelines

System namespaces stay admin-only. App namespaces follow a <team>-<env> pattern instead of default.

Rollout plan

  1. Collect the real user list and assign each person a tier.
  2. Issue per-user certificates with CN=<user> and O=<role group>.
  3. Keep the RBAC manifests in Git and apply them from there.
  4. Build one kubeconfig per user, delivered out of band. The admin kubeconfig is never reused.
  5. Enable API server audit logging so every request is attributable before more people get access.
  6. Verify each tier with positive and negative kubectl auth can-i checks.
  7. Document issuance, rotation and revocation. Certificate revocation is manual, so use short-lived certificates or move to OIDC.
  8. Once the identity provider is ready, configure the API server for OIDC, add group subjects to the bindings and retire the certificates in favor of kubelogin.

A companion runbook drafts the OIDC side with Authentik: groups, an OIDC provider, the API server’s authentication configuration, group bindings, kubelogin for people and ServiceAccounts for agents and CI.