ALB validates the JWT, Keycloak decides what is in it: the Terraform for the matching realm

The gateway checks a signature and looks for claims. It cannot add one. So the useful part of this stack is not the ALB policy but the client scope, which the author describes as the shared set of protocol mappers attached to the client ^[12]: whatever is not mapped there does not exist as far as the cluster is concerned.

The narrowing starts with the client flags. On the `kube-api` client, one flow toggle is on, `standard_flow_enabled`, which the author identifies as the authorization code grant ^[5]. Six are off: implicit, direct access grants, service accounts, standard token exchange, the OAuth2 JWT authorization grant and device authorization ^[6][18]. `full_scope_allowed = false` limits the token to roles scoped to this client ^[7]. With the direct access grant disabled, there is no password-grant shortcut for a test token; anything the gateway sees has to come back through one of the four registered redirect URLs ^[8][19], two loopback ports for kubelogin ^[9] and two Postman callbacks ^[10]. That constraint is exactly why runners need their own path, and the author's JWT-federated GitHub Actions client is deferred to a future article ^[3].

The membership side is looser than the client side. `keycloak_user_groups` is declared with `exhaustive = false` ^[13], and the `kube-admin` group carries the client role named `admin`, described in the code as the cluster-admin role for kube-api ^[14][11]. Non-exhaustive means Terraform owns the rows it declares and ignores the rest, so a hand-added member of that group is not drift anyone will be shown.

Two other lines are worth reading as policy rather than plumbing. `email_verified = true` is set from config for every user the stack creates ^[15], which is the realm asserting a fact about a person rather than the person proving it. And `lifecycle { ignore_changes = [first_name, last_name] }` ^[16] hands display names back to the directory while leaving `username` under Terraform control, which matters because `username` is the one attribute the article shows being copied into both the access token and the ID token ^[17][20]. Rename it in config and you rename the subject the cluster authorizes.

Which is where the walkthrough stops short of its own promise. The role resource is said to appear in the token's role claim once assigned to a user ^[11], but the mapper set published here contains only the username mapper, and the text breaks off mid-explanation of `add_to_id_token` ^[22][23]. Follow it literally and you get a token the gateway will accept carrying an identity and no authorization data.

One last asymmetry. The provider itself authenticates with a service-account client using the client credentials grant, driven by five environment variables and an otherwise empty `provider "keycloak" {}` block ^[2]. Service accounts are precisely what the `kube-api` client forbids ^[6][21]. The realm-management credential and the human credential are different clients with opposite capabilities, which is correct, and also means the secret that can rewrite every role mapping in this stack lives wherever the plan runs.