K
Q

Kubernetes service account role using OIDC

12/2/2019

I am trying out the capability where 2 pods deployed to the same worker node in EKS are associated to different service accounts. Below are the steps

  • Each service account is associated to a different role one with access to SQS and other without access.
  • Used eksutil to associate OIDC provider with cluster and also created iamserviceaccount with service account in kubernetes and role with policy for accessing SQS attached (implicit annotation of service account with IAM role provided by eksctl create iamserviceaccount).

But when I try to start the pod which has service account tied to role with SQS access, I am getting access denied for SQS, however if I add SQS permissions to worker node instance role, its working fine.

Am I missing any steps and is my understanding correct?

-- rajesh kumar
amazon-eks
eksctl
kubernetes
kubernetes-pod
openid-connect

Similar Questions

Kubernetes deployment high memory usage
Google debug: How to debug a library in executable jar - Error : File was not found in the executable
Can we have static Kubernetes PV names with dynamic hostpath provisioner(rancher) ..?
Kubernetes pod cluster ip not responding?
NumberFormatException when starting Quarkus on Kubernetes

1 Answer

12/2/2019

So, there are a few things required to get IRSA to work:

  1. There has to be an OIDC provider associated with the cluster, following the directions here.
  2. The IAM role has to have a trust relationship with the OIDC provider, as defined in the AWS CLI example here.
  3. The service account must be annotated with a matching eks.amazonaws.com/role-arn.
  4. The pod must have the appropriate service account specified with a serviceAccountName in its spec, as per the API docs.
  5. The SDK for the app needs to support the AssumeRoleWithWebIdentity API call. Weirdly, the aws-sdk-go-v2 SDK doesn't currently support it at all (the "old" aws-sdk-go does).

It's working with the node role because one of the requirements above isn't met, meaning the credential chain "falls through" to the underlying node role.

-- asthasr
Source: StackOverflow