Kubernetes Group Identity Management

Kubernetes Group Identity Management is the discipline of organizing user access around named collections of subjects — groups — rather than granting permissions to individual users one at a time. Because Kubernetes has no native concept of a group object, group management in practice means designing how an external authentication source expresses group membership, and how that membership is translated into durable, reviewable RBAC bindings across the cluster.

Where Groups Come From

Certificate-Based Groups

When authenticating with X.509 client certificates, group membership is carried in the certificate's Subject Organization (O) field. A certificate can list multiple organizations, each becoming a distinct group the bearer belongs to for the lifetime of that certificate. Because the group list is baked into the certificate at issuance time, changing someone's group membership requires re-issuing their certificate.

OIDC Claims

OIDC-based authentication typically maps a configurable token claim — commonly named groups — to Kubernetes group membership. The identity provider computes this claim at token-issuance time from its own directory structure, so adding or removing a user from a group in the identity provider changes their effective Kubernetes permissions the next time they obtain a token, without any change inside the cluster itself.

Webhook-Derived Groups

A webhook authenticator can return an arbitrary group list as part of its TokenReview response, allowing organizations with custom identity systems to compute group membership using their own logic and surface it to Kubernetes in the same shape as OIDC or certificate groups.

Built-In System Groups

system:authenticated and system:unauthenticated

Every request that passes authentication is automatically placed in system:authenticated; anonymous requests are placed in system:unauthenticated. These groups let administrators write baseline bindings — for example, granting system:authenticated read access to public ConfigMaps — that apply to any successfully authenticated identity regardless of its origin.

system:serviceaccounts and Namespaced Variants

All service accounts cluster-wide belong to system:serviceaccounts; service accounts within a specific namespace additionally belong to system:serviceaccounts:<namespace>. These groups let administrators grant a permission to every workload in a namespace without enumerating individual service accounts.

Binding Permissions to Groups

Group Bindings in Practice

Binding a ClusterRole or Role to a Group subject, rather than to individual User subjects, means the binding never needs to change as team membership changes — only the external directory's group membership needs updating.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sre-view-all
subjects:
- kind: Group
  name: oidc:sre-team
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Namespace-Scoped Group Roles

For multi-tenant clusters, a common pattern binds a team's group to an edit or custom Role inside only the namespaces that team owns, using a RoleBinding per namespace rather than a single cluster-wide grant, keeping the group's effective access aligned with organizational boundaries.

Designing a Group Taxonomy

Aligning Groups with Organizational Structure

Effective group naming mirrors real organizational units or functional responsibilities — platform-admins, payments-developers, read-only-auditors — so that the mapping between a group name in a RoleBinding and the humans it affects remains self-evident during review.

Avoiding Group Sprawl

Because every distinct group referenced across bindings must be tracked back to its source in the identity provider, creating narrowly-scoped, one-off groups for individual permissions tends to produce a taxonomy that is difficult to audit; broader, role-oriented groups combined with fine-grained Role definitions usually scale better.

Auditing Group-Based Access

Reviewing Effective Membership

Since Kubernetes never materializes group membership as a queryable object, determining who currently has access through a given group requires consulting the identity provider directly rather than the cluster — a governance gap that should be closed by periodic joint review of ClusterRoleBinding/RoleBinding subjects against the identity provider's group rosters.

Group Claim Integrity

Because group membership arrives embedded in a token or certificate that the API server trusts implicitly, the security of group-based authorization is only as strong as the process that issues those credentials; a compromised identity provider or a misconfigured claim mapping can silently grant unintended cluster-wide access.