Skip to content

EKS Auto Mode Load Balancer Controller unable to build ingress model when adding auth annotations due to insufficient permissions on AWSServiceRoleForAmazonEKS

0

I'm attempting to migrate from ingress nginx controller to an application load balancer, but have requirements to authenticate with oidc. I've added annotations to the required ingresses, however I'm getting errors in the cluster along the lines of: Failed build model due to ingress: monitoring/<INGRESS>: secrets "oidc" is forbidden: User "arn:aws:sts::<ACCOUNT>:assumed-role/AWSServiceRoleForAmazonEKS/<SESSION>" cannot get resource "secrets" in API group "" in the namespace "monitoring"

I'm unable to add any additional policy (such as AdminViewPolicy to get secrets) to AWSServiceRoleForAmazonEKS due to this error: The caller is not allowed to modify access entries with a principalArn value of a Service Linked Role, nor can I add any groups to the access entry. As I am using Auto Mode, I have no visibility of the LBC, so I can't find a way to change which access identity it is using/to give it the required permissions - although this feels like something that should be supported by EKS auto mode if the LBC is supported by default? Am I missing something to enable access to this secret, or can someone point me to any documentation on this if i've missed a step?

asked 2 years ago186 views

1 Answer
0

When using EKS Auto Mode, the IAM Role for Load Balancer creation is the Cluster IAM role. This can be viewed in the AWS console on the Overview tab. Or from the AWS CLI command:

aws eks describe-cluster --name <your-cluster-name> --query "cluster.roleArn" --region <your-region>

The Cluster IAM role appears to be of the form: <cluster name>-cluster-<timestamp>

That IAM role is not a service-linked role, and you can add whatever policies you like to it.

The nice thing about EKS Auto Mode is that it saves you the work of having to setup an IAM Role, IAM Policy, ServiceAccount, or running Helm. I illustrate of all that here

answered 2 years ago

  • Thank you for your reply! I have indeed got the cluster role setup - the issue here is by default the service role that AWS uses to access the cluster does not have permission to view any secrets. The role uses a session-based username when connecting to the cluster so currently we are unable to give it any additional permissions.

    I created an issue on the container roadmap, and the role is going to be adjusted to use a fixed username when interacting with the cluster so it's access can be increased where it's needed. Once rolled out, we should be able to add a cluster role binding to the user arn:aws:sts::<account>:assumed-role/AWSServiceRoleForAmazonEKS/* within the cluster to allow secrets access.

    (Just to add - your article is very descriptive and useful!)

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.