Aws-iam-authenticator: Feature request: Map IAM username and groups automatically to Kubernetes.

[olafure]

This is a promising project, thanks!

For it to be manageable in clusters with audit requirements, it'd need to be able to automatically map IAM usernames and groups to Kubernetes.

The Kubernetes audit contains the username, and it isn't useful if it's the same for all users.

I know you can statically map them in the configuration file, but it defies the purpose of this project if you have to update the authenticator configuration when you add/remove an IAM user.

Something like:

• Node has IAM access to query IAM user groups
• config:
  mapUsers:
  
  
  
  • autoMapped: true
    
    kubernetesUserPrefix: "my:"
    
    kubernetesGroupPrefix: "my:"
  
  

User 'bob' (member of 'dev' and 'staging') logs in.
Authenticator queries his groups and assigns him the Kubernetes username "my:bob" and group membership "my:dev" and "my:staging"

[mattlandis]

I like this idea but think we should spend some more time gathering use cases and working through any corner cases or potential gotcha's.

Should it map for all users? Should it map all groups? Does it make sense for authenticator to call ListGroupsForUser in real time or can something watch for changes to users and groups and update them in the mappings?

I'd love to hear from other community members on how it would fit in their use case.

[pib]

@mattlandis I think being able to specify some kind of filter on allowed users and groups would be useful. For users, it could be zero or more simple string matches with wildcards, and/or zero or more path prefixes to limit to, for those using paths for their users.

For groups, the same idea would be useful, an optional list of strings with wildcards to match against, so you could limit it to groups starting with an environment- or cluster-specific prefix, for example.

[expnch]

I'd also like to see this kind of functionality. When initially configuring the authenticator on EKS, I was hoping to map IAM groups to K8s users in some way, as that's the most convenient way to control access and privilege in IAM.

What @pib describes would definitely make my life more convenient.

Because I don't need audit capacity, my workaround was to (1) create IAM roles (EKS_Admin, EKS_User) that are mapped to generic K8s users (my:admin, my:user) and (2) create trust relationships that allow my users to assume the appropriate role. This is pretty clunky and probably a misuse of IAM roles, but at least lets me manage access and permissions from within AWS.

[casey-robertson]

I'd also like to see this kind of functionality. When initially configuring the authenticator on EKS, I was hoping to map IAM groups to K8s users in some way, as that's the most convenient way to control access and privilege in IAM.

What @pib describes would definitely make my life more convenient.

Because I don't need audit capacity, my workaround was to (1) create IAM roles (EKS_Admin, EKS_User) that are mapped to generic K8s users (my:admin, my:user) and (2) create trust relationships that allow my users to assume the appropriate role. This is pretty clunky and probably a misuse of IAM roles, but at least lets me manage access and permissions from within AWS.

Might do this too for now.

[vinmazzi]

@olafure Let me know if this helps you.

https://github.com/vinmazzi/aws-iam-authenticator/commit/0c599bd8a05fcf2720c22130abf095826a6ea1be

Basically what I did was to add a flag '-u' to aws-iam-authenticator where you specify your IAM username.

This username on the flag will be used as a session name for the assumeRole, it can then be accessed as {{SessionName}} variable on kubernetes configmap.

Example:

kubeconfig:

...
users:
- name: vinicius.mazzi
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - k8s.myclustername.local
      - -r
      - arn:aws:iam::000000000000:role/Developers
      - -u
      - vinicius.mazzi
      command: aws-iam-authenticator

configmap/aws-iam-authenticator:

...
  - roleARN: arn:aws:iam::000000000000:role/Developers
    username: {{SessionName}}
    groups:
    - system:masters
...

[whereisaaron]

Hi @vinmazzi , assume-role session names can be anything you want. So, with that approach, can't the end-user then specify any username that want? So it can't actually be used for mapping cluster users/permissions? Or am I missing something? 🤔

[vinmazzi]

@whereisaaron You are right, that's why I'm validating if the user specified in -u is the same returned on sts get-caller-identity.

I'm doing the validation here: https://github.com/vinmazzi/aws-iam-authenticator/commit/0c599bd8a05fcf2720c22130abf095826a6ea1be#diff-377f345aee2af2705336395c308148f4R227

One thing I just noticed is that, there's no need for -u, I could have used sts get-caller-identity right from the start. lol

:)

[olafure]

Thanks @whereisaaron
If I understand this correctly, then you need an entry in the users array for each user you want to map?
Like:

users:
- name: vinicius.mazzi
  ...
- name: another.user
  ...
- name: and.another
  ...

[vinmazzi]

@olafure no, I'm actually avoiding a user array.
The {{SessionName}} will represent the username. For example, if I'm authenticating with 'vinicius.mazzi' {{SessionName}} will be 'vinicius.mazzi'.

You will have a role array instead:

...
  - roleARN: arn:aws:iam::000000000000:role/Developers
    username: "{{SessionName}}"
    groups:
    - developers

  - roleARN: arn:aws:iam::000000000000:role/admins
    username: "{{SessionName}}"
    groups:
    - admins
...

vinicius.mazzi will only be able to be admin in this case if the policy allows him to assume an admin role.

[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

[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.