Interesting that they use a single IAM role per client. This will also run into limits (which can be upped), but wouldn’t a better design be to use a single role with a specific STS session name and session tag enforcement policy?
You can then say this role can read/write to “s3://bucket/${account-tag-name}/“ and have it enforced.
Because they use a single service account per client, which has no limits as far as I know, they can add a IAM assume role policy to say “the client-ID session tag must match the Kubernetes service account name” or something like that.
What’s annoying is that you can’t go any more granular than the service account name - currently there is no way to create a pod IAM role with specific pre-baked tags, so you can’t say like “this IAM session can only be assumed when tag X equals the k8s pod label value Y”.
Being able to do this would be insanely valuable for specific and fairly niche IAM problems. As I understand it, it’s a limitation with Kubernetes.
First time poster, long time lurker. I'm a fairly proficient kubernetes admin and developer. I'm using it in depth every day. It seems like that functionality would be really easy to add to the IRSA (iam roles for service accounts). Is it judt that nobody has bothered, or am I missing an important blocker?
The issue as I understand it is that there is no way to encode this information in the Kubernetes token.
The pod IAM roles stuff leverages Kubernetes stuff, and the token that’s mounted into the container is a YAML representation of a Kubernetes token object. There are no fields or other way to add this information into the object.
You would need to encode it into the JWT itself, which isn’t possible or something.
I’m half remembering this, and I can’t find the issue on Guthub because everything has been shuffled around since.
You can then say this role can read/write to “s3://bucket/${account-tag-name}/“ and have it enforced.
Because they use a single service account per client, which has no limits as far as I know, they can add a IAM assume role policy to say “the client-ID session tag must match the Kubernetes service account name” or something like that.
What’s annoying is that you can’t go any more granular than the service account name - currently there is no way to create a pod IAM role with specific pre-baked tags, so you can’t say like “this IAM session can only be assumed when tag X equals the k8s pod label value Y”.
Being able to do this would be insanely valuable for specific and fairly niche IAM problems. As I understand it, it’s a limitation with Kubernetes.