Aws-iam-authenticator: Support for assumed role ARNs

[JacobHenner]

Hello,

Are there any plans to support assumed-role ARNs for authentication?

Right now, both IAM role and IAM user ARNs are supported, but not STS assumed role ARNs.

This would be helpful, as it would allow maintainers to provision access not just by role (which may map to many users), but by role and username (as the name of the role session).

For example, instead of:
arn:aws:iam::account-id:role/role-name

Support:
arn:aws:sts::account-id:assumed-role/role-name/role-session-name

Thanks

[casey-robertson]

This is our auth model (brand new to AWS/EKS)... yeah, not having assumed role support is going to be a deal breaker.

[nckturner]

You can currently only map each role to a username and set of groups, but you can pass the session name into Kubernetes as the username and create an RBAC role binding there per session name, if you need different permissions per session name.

  - roleARN: arn:aws:iam::123456789012:role/Admin
    username: admin:{{SessionName}}
    groups:
    - system:masters

If the session name is bar, then:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin
  namespace: foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: admin:bar

Does that work for you?

[nckturner]

The caveat is that session names are chosen the the assumer, so this only works if you have a system where the user asking for credentials is not able to set this value.

[micahhausler]

I think the request is just to support STS ARNs in addition to IAM ARNs since

arn:aws:iam::111122223333:role/some-path/role-name
# or 
arn:aws:iam::111122223333:role/role-name

both get the sts:GetCallerIdentity output of:

arn:aws:sts::111122223333:assumed-role/role-name/role-session-name

I think that the tricky part about adding support for STS ARNs is answering the question, "What if the IAM ARN and the STS ARN are defined for the same role, but to different usernames and groups?" Does the last one win? How do I debug that?

[yuft]

From https://aws.amazon.com/blogs/opensource/integrating-ldap-ad-users-kubernetes-rbac-aws-iam-authenticator-project/

For the rolearn be sure to remove the /aws-reserved/sso.amazonaws.com/ from the rolearn url, otherwise the arn will not be able to authorize as a valid user

This works for me.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Japeth]

yuft is spot on. In my case I was using an assumed role into the account that had the k8s cluster, which was not the same account that built the cluster (we used a separate terraform user to create the cluster). I had to take out the /aws-reserved/sso.amazonaws.com/us-west-2 from the Role ARN and add that to the aws-auth configmap as a Role Mapping.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.