The metadata service answers any caller that can reach it, and returns credentials for the node identity rather than for any workload identity
Whether an ordinary pod can reach it is a platform and provisioning property, not a Kubernetes one, so the required pod shape differs per cluster
Where the address is redirected per pod network namespace, as GKE does with GKE_METADATA, a hostNetwork pod runs in the host namespace and reaches the real service
Where nothing intercepts it, which is the AKS default and the eksctl default on EKS, a plain unprivileged pod reaches it with no host access at all
On EKS the barrier is the IMDSv2 hop limit of 1, and it holds only while tokens are required.
An IMDSv1 GET is not hop limited and returns the credentials anyway
Workload identity does not prevent this.
It changes which credential the SDK resolves, not which address the pod can reach, and a hostNetwork pod always reaches it
Mounting the host root as root is an independent second route, reading the kubelet credentials and the cloud provider config from disk
The node identity ceiling varies from no cloud permissions at all to full control of the node resource group, so read its role bindings before rating impact
Rights needed, any one set:
· scoped to a cluster where nothing intercepts the metadata address, such as AKS by default or EKS at hop limit 2
· no privilege and no host namespace needed
· scoped to hostNetwork or a host root hostPath mount
· needed where the platform redirects or hop-limits the address; the privileged flag itself is not
Note:
Working as designed rather than a fixable defect.
Whether a plain pod is blocked depends on the platform and on how the node group was set up.
On EKS the control is the hop limit together with required tokens, not either one alone.