EKS Pod Identity for Karpenter running on host network

Why it works without hostNetwork but fails with it ... ->

The reason it works when hostNetwork: false is that the Pod is likely falling back to IRSA (OIDC). In a standard setup, the AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN environment variables are injected. When the Pod is in the overlay network, it uses the OIDC provider to assume the role.

However, when you switch to hostNetwork: true, the networking path to the metadata service changes. EKS Pod Identity (the newer method) uses a local agent on the node (169.254.170.23).

EKS Auth vs. OIDC

The error message AccessDeniedException: EKS does NOT have permissions to assume the associated role specifically comes from the EKS Auth Service, not the OIDC provider.

So, even if your "Role / Service Account Association" is correct for IRSA, it is likely missing the specific requirement for EKS Pod Identity:

• The Trust Policy Problem: IRSA requires oidc.eks... in the Trust Policy. EKS Pod Identity strictly requires pods.eks.amazonaws.com. If you only have the OIDC provider in your Trust Policy, the EKS Auth Service is denied permission to "hand out" that role to a pod on the host network.
• The Session Tagging: Unlike IRSA, EKS Pod Identity requires the sts:TagSession permission in the Trust Policy. Without it, the EKS Auth API call will fail even if the Service Principal is correct.

In short: Your setup works without hostNetwork because it's using the OIDC (IRSA) flow. When you enable hostNetwork, the traffic shifts towards the EKS Pod Identity Agent. This agent uses the EKS Auth Service, which does not have permission to assume your role unless you explicitly add pods.eks.amazonaws.com to your IAM Role's Trust Relationship.

see:

• https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-iam-role

PS: could you try to run this command to check if your IAM Role actually trusts the EKS Pod Identity service:

aws iam get-role --role-name <YOUR_KARPENTER_ROLE_NAME> --query 'Role.AssumeRolePolicyDocument'

If you only see oidc.eks.<region>.amazonaws.com in the output, it will never work with Pod Identity on the host network. You must add the new service principal.

EKS Pod Identity requires sts:TagSession in addition to sts:AssumeRole. IRSA often works without explicit tagging permissions, but Pod Identity does not.

As far as I'm right, your Trust Relationship must include this block to allow the EKS Auth service to "speak" to your role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

see also:

• https://github.com/aws/amazon-eks-pod-identity-webhook/issues