liveBook · Manning

Federated identity integration

As explained in Kubernetes for Developers

Identity federation is an integration pattern that lets an external identity provider authenticate identities for another system.

Federated identity integration lets Kubernetes authenticate developer identities through an external identity provider, then lets RBAC use those identities as Users and Groups. GKE natively recognizes Google users and can recognize Google groups when Google Groups for RBAC is enabled; other platforms may require OpenID Connect (OIDC) integration. section 12.6

Groups reduce administration: bind a Role or ClusterRole to one group instead of listing every individual user. The identity-provider setup depends on the platform and remains separate from defining Kubernetes permissions. section 12.6

How Kubernetes for Developers covers it

How deep it goes
Explains the integration purpose and group-based bindings, but defers identity-provider setup and configuration details.
Examples
Uses GKE Google users, Google Groups for RBAC, and individual-user versus group role bindings as concrete cases.
What it assumes
Assumes familiarity with Kubernetes RBAC subjects and permissions while introducing external authentication as the identity source.
What you can do after
Evaluate how an external identity system can supply Kubernetes RBAC subjects and when group bindings can simplify administration.
How it connects
Links identity providers and OpenID Connect to Kubernetes RBAC, Users, Groups, Roles, and ClusterRoles.

Also explained in

Compare how 3 books explain federated identity integration →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes for Developers. The section links point to the parts of the book it draws on.