Giters

ex-aws / ex_aws

A flexible, easy to use set of clients AWS APIs for Elixir

Home Page:https://hex.pm/packages/ex_aws

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ex_aws and ex_aws_sts does not seems to support IAM authentication within EKS?

danibachar opened this issue · comments

commented
  • Do not use the issues tracker for help or support (try Elixir Forum, Slack, IRC, etc.)
  • Questions about how to contribute are fine.

Environment

  • Elixir & Erlang versions (elixir --version):1.16
  • ExAws version mix deps |grep ex_aws: 2.5.2 (ex_aws_s3: 2.5.2, ex_aws_sts: latest)
  • HTTP client version. IE for hackney do mix deps | grep hackney

Current behavior

I have an EKS cluster, when deploying a Deployment using a docker file. The SDK seems to fail to authenticate with the the ServiceAccount that is attached to that deployment.
It seems to default to an instance_role and auth with an IAM role of the nodes in the cluster.
In our example this IAM role does not have permissions to operate with an S3 bucket. Only the IAM role we have configure with the ServiceAccount.

I have checked that the newly create IAM role has succfient permissions and can operate with the relevant S3

Expected behavior

Working within EKS the SDK should work like any other AWS SDK and allow assuming/working with the IAM role that is attached to a Pod/Deployment using a ServiceAccount

commented

👋🏼 We are interested in contributing to this. Could you let us know if this aligns with the library's direction and perhaps provide some pointers around how you'd expect it to be implemented?

commented

Thanks Pedro!
the containers in your Pods must use an AWS SDK version that supports assuming an IAM role through an OpenID Connect web identity token file.

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html

commented

To add to what to @danibachar, in order for this sdk to be able to run properly in EKS using service accounts, I think you'll need to implement something like this in the default credential provider chain for this SDK.

commented

Hi,
Is there any known workaround right now ? Giving permissions to the node (instance) directly is clearly a very bad practice, and I would like to avoid that as much as possible.

Thanks !