Hacker News Reader

Comment by bearforcenine | Hacker News Reader

>we need to set up a way to manage AWS IAM credentials to Kubernetes pods... In a production system, this should be done using a tool such as kube2iam or kiam...

I am curious if AWS has any plans to build an IAM integration for K8s that provides IAM credentials/roles directly to pods. An integration through EKS or K8s directly would make interacting with AWS resources very easy.

Being able to authenticate to the K8s cluster using https://github.com/kubernetes-sigs/aws-iam-authenticator is nice, but it doesn't help give pods IAM roles.

View on HN

https://github.com/jtblin/kube2iam is probably what you're looking for, it uses iptables to allow/disallow pods requests to the ec2 metadata service based on kubernetes annotations

in fact, if you check out the source (located here: https://github.com/awslabs/aws-service-operator) it's recommended to use kube2iam

edit: haven't fully read the article yet but if the operator supports managing IAM roles thru a CRD you could potentially create the role and attach it via annotation in one go.

double edit: looks like IAM roles aren't directly supported yet, the following is what appears to be supported:

- cloudformation templates

- dynamodb

- s3

- sns subscriptions and topics

- sqs queues

- ecr repos

I understand that both kube2iam and kiam exist and they're both fine. I am interested in Amazon/EKS directly supporting something. Hopefully we will see something soon via CRD or otherwise.

If I still need to create an IAM role externally for the pod granting it access to the different resources.. Might as well create the resources themselves as well?

Correct, they are on the roadmap, I've been waffling on the implementation because this could open security issues. I'm happy to say we'll at least be able to use k8s RBAC to gate who can get, list, create, update and delete the Roles but your security posture from the node perspective still will need to gate what the pods could assume. https://github.com/awslabs/aws-service-operator/issues/58 https://github.com/awslabs/aws-service-operator/issues/59 are the issues if you'd like to add any extra notes or check out the potential implementation.

We've been using kube2iam for this for a couple of years.

You just create a role give it an assume role policy that allows the node to assume it. Then annotate your pod w/ the role arn. When they make a call to get their instance profile you get the role instead.

It's a little annoying in that your pod code thinks its making a metadata call (which is super super fast), but what is actually happening is kube2iam intercepted that and will make a sts:assumerole call... which takes forever. So people just need to set their timeout a little higher than normal.

https://github.com/jtblin/kube2iam

This is something we’ve heard a lot and are working together with the Kubernetes community on. We’ll have more to announce on this one soon

Full disclosure: I work on EKS at AWS

This is exciting to hear. I look forward to hearing more.

I too am excited to hear more. The necessity for kube2iam and kaim are one of the major blockers that have prevented us from considering EKS for a client, the major sticking point being that they move the implementation of shipping security material around from the AWS to the customer side of the shared responsibility model.

AWS always launches services half-baked - I actually kinda love them for it. It's not always polished, but it's usually good enough to help me get stuff done.

I'm sure we'll see much tighter integration over time.

I bet you could register the containers as on-prem instances with the Systems Manager agent, though it's kind of a pain. It gives you a shim into IAM from non-AWS machines.

(I work at AWS SSM, but not directly on the on-prem featureset.)

Reply on news.ycombinator.com