(eks): need to override kubectl handler lambda IAM role

we’ve noticed that when we want to create the service account through cdk with IAM role attached, the cdk requires us to specify the IAM role that has access to Kubernetes API:

Also, we’ve noticed that the lambda that does kubectl apply tries to assume that role to make kubectl apply command, which is fine.

The one thing that we noticed that when this kubectl handler lambda created it is created with the new role every time with the assume role inline policy.

Which is could be fine as well but we find that this is not quite secure, because in this case, we need to put “root account” to the trusted entities of kubectlRole to let all that lambdas assume this role.

For dev/qa environments it is fine but for production account, we really don’t want to have Kubernetes admin role which can be assumed by anyone who has assumeRole policy we want to tight that kubectl role by trusted entities some how.

Use Case

we use IRSA for Imported clusters service-per-service. Each service has it’s own cdk stack with Cluster.addServiceAccount() call. So each service create it’s own kubectl handler lambda with it’s own lambda role with random name.

our kubectl role should be assumable by only one entity, but in the environment where we have huge amount of lambdas for each service it is not possible to list all that lambda roles in the trusted entity of kubectl role.

Proposed Solution

I see here two possible solutions:

1. Add an optional parameter with the kubectl handler lambda. so each cdk stack can load that lambda and use the same lambda in a different stacks that creates IRSA. So we create that lambda once with the role and put that role to the trusted entity of kubectlRole.
2. Add an optional parameter to .addServiceAccount() function to pass the existing role arn for kubectl handler lambda. so we can create that role once, put it inside the trusted entities of kubectl role and all kubectl handlers will run under this role.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[aka-toxa]

yes I’m preparing the draft changes for that, it is a bit tough will show soon I’m almost done

[iliapolo]

@aka-toxa Let me know when you start working on this to finalize the approach because i’m still not sure about it.