I've recently been making use of the GKE Workload Identity feature. I'd be interested to know in more detail how the gke-metadata-server
component works.
- GCP client code (
gcloud
or other language SDKs) falls through to the GCE metadata method - Request made to
http://metadata.google.internal/path
- (guess) Setting
GKE_METADATA_SERVER
on my node pool configures this to resolve to thegke-metadata-server
pod on that node. - (guess) the
gke-metadata-server
pod with --privileged and host networking has a means of determining the source (pod IP?) then looking up the pod and its service account to check for theiam.gke.io/gcp-service-account
annotation. - (guess) the proxy calls the metadata server with the pods 'pseudo' identity set (e.g.
[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
) to get a token for the service account annotated on its Kubernetes service account. - If this account has token creator / workload ID user rights to the service account presumably the response from GCP is a success and contains a token, which is then packaged and set back to the calling pod for authenticated calls to other Google APIs.
I guess the main puzzle for me right now is the verification of the calling pods identity. Originally I thought this would use the TokenReview API but now I'm not sure how the Google client tools would know to use the service account token mounted into the pod...
Edit follow-up questions:
Q1: In between step 2 and 3, is the request to metadata.google.internal
routed to the GKE metadata proxy by the setting GKE_METADATA_SERVER
on the node pool?
Q2: Why does the metadata server pod need host networking?
Q3: In the video here: https://youtu.be/s4NYEJDFc0M?t=2243 it's taken as a given that the pod makes a GCP call. How does the GKE metadata server identify the pod making the call to start the process?