kubernetes
Pod authentisiert sich mit seinem
ServiceAccount-JWT; Vault validiert es gegen die
TokenReview-API des Clusters. Config:
kubernetes_host. Vault im Pod:
token_reviewer_jwt und CA weglassen, Vault liest das
lokale SA-Token periodisch neu. Vault extern: ohne
token_reviewer_jwt dient das Client-JWT als Reviewer
(Clients brauchen system:auth-delegator), CA per
kubernetes_ca_cert. Die Role bindet
bound_service_account_names +
..._namespaces an Policies.
vault auth enable kubernetes vault write auth/kubernetes/config \ kubernetes_host=https://10.0.0.1:443 \ kubernetes_ca_cert=@ca.crt vault write auth/kubernetes/role/app \ bound_service_account_names=myapp \ bound_service_account_namespaces=prod \ token_policies=app-ro token_ttl=1h
AppRole
Für Maschinen/CI: RoleID (quasi
Username) + SecretID (geheim,
Pull-Mode empfohlen). SecretID mit
secret_id_ttl und secret_id_num_uses
begrenzen; Zustellung an die App über Response
Wrapping (kurzlebiges Wrapping-Token) statt Klartext.
token_type=batch empfohlen.
OIDC / JWT
Zwei Modi einer Methode: oidc = interaktiver
Redirect-Flow (Authorization Code + PKCE,
oidc_discovery_url + Client-ID/-Secret) für
Menschen; jwt = Bearer-JWT gegen JWKS/statische
Keys für Workloads/CI.
jwt-Rollen: Trägt das JWT einen aud-Claim,
muss ein Eintrag in bound_audiences exakt passen
(oidc-Rollen: optional); bound_claims
prüft weitere Claims; user_claim bestimmt den
Entity-Alias.