I would like to understand one thing on OpenId Connect and GKE to better manage IAM and RBAC.I cannot find any info on this:
1. I'm Project Owner in my GCP project
2. After applying
gcloud container clusters get-credentials $CLUSTER --zone $ZONE
my .kube.conf is populated.
3. I can get my id_token
gcloud config config-helper --format=json
4. Using for example jwt.io I decode id_token, where my payload part is:
{
"iss": "https://accounts.google.com",
"azp": "3[redacted]9.apps.googleusercontent.com",
"aud": "3[redacted]9.apps.googleusercontent.com",
"sub": "1[redacted]9",
"hd": "[redacted].sh",
"email": "maciej.leks@[redacted].sh",
"email_verified": true,
"at_hash": "e[redacted]g",
"iat": 1[redacted]6,
"exp": 1[redacted]6
}
So, the question is what really happens there that my jwt sub or email is mapped into the right Group inside the cluster while there is no ClusterRoleBinding with me (e.g. email) as a subject? In this Default discovery roles of GKE doc there is something about it but it's so enigmatic that I still do not understand what happens between sending my id_token as Baerer and finally being properly authenticated as me and authorized as a Group (which Group: system:basic-user, system:masters,...?)
I don't think they have ever said publicly. Kubernetes does natively support group claims in OIDC tokens however as you said, there are none in Google tokens so we know it isn't using that. Given the deep integration between GCP IAM and GKE it's generally assumed the Google internal fork has some custom admission control plugins, either tweaking or replacing the core code with GCP-specific bits. It's also possible they use the webhook token authentication mode with a custom receiver. Either way, Google doesn't generally discuss such things so we will probably never know in a confirmable way.