Eksctl: authconfigmap: command to manipulate aws auth configmap

[rndstr]

PR #623 attempted to add a command to modify the auth configmap but its location and command hierarchy needs a bit more discussion.

The auth ConfigMap is in kube-system and named aws-auth. It contains various mappings of IAM/AWS entities to Kubernetes groups.

More information at

• https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html
• https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/README.md#full-configuration-format

A. command design

The command should provide the following invocations (with description of current implementation of feature)

• display the current config
• add a role by arn, username, and groups
  
  
  
  • no de-duplication with existing mappings (related to #544)
  
  
• remove a role by arn
  
  
  
  • remove a single role even if there are duplicates (see #544)
  
  
  • fail if role not found
  
  
• add an account number
  
  
  
  • de-duplicate
  
  
• remove an account number
  
  
  
  • fail if account number not found
  
  

Some ideas and the start of the discussion can be found in #623.

It seems like that the following fulfills most of our constraints:

eksctl get aws-auth
eksctl update aws-auth add-role <arn> --username <string> --groups <csv>
eksctl update aws-auth remove-role <arn>
eksctl update aws-auth add-account <number>
eksctl update aws-auth remove-account

some variations:

• add => map && remove => unmap
• aws-auth => auth

B. command behavior

Further discussion can be had about changing the way commands behave:

• remove a role
  
  
  
  • TBD: remove by role arn only? or match username and groups?
  
  

[errordeveloper]

For the record, we have a712049 that reverted the first implementation, so that can be reverted back.

[errordeveloper]

xref #62

[rndstr]

Somre more thoughts on naming

• the flag --update-auth-config-map for eksctl create|delete nodegroup describes the same thing
• iam-auth-bindings has been brought up to bring it on par with upcoming IAM features

So more options

• eksctl update iam-auth-bindings|iam-auth
• eksctl update auth-config-map|auth-configmap

[StevenACoffman]

If it is helpful, our use case is that we have four IAM roles: eksctl, read-only, developer, and admin. Our AWS accounts have no access rights except to assume one (or more) of those roles based on group membership.

When we create a new cluster, we have a horrible bash script that inserts into the aws-auth configmap a few lines after the line: mapRoles: |:

    - rolearn: arn:aws:iam::${AWS_ACCOUNT_ID}:role/${EKSCTL_ROLE}
      username: admin:{{AccountID}}:{{SessionName}}
      groups:
        - system:masters
    - rolearn: arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ADMIN_ROLE}
      username: admin:{{AccountID}}:{{SessionName}}
      groups:
        - admins
    - rolearn: arn:aws:iam::${AWS_ACCOUNT_ID}:role/${EDIT_ROLE}
      username: editor:{{AccountID}}:{{SessionName}}
      groups:
        - editors
    - rolearn: arn:aws:iam::${AWS_ACCOUNT_ID}:role/${VIEW_ROLE}
      username: viewer:{{AccountID}}:{{SessionName}}
      groups:
        - viewers

The RBAC parts we can manage easily enough, but automated edits to that file are a real pain.

[rndstr]

Keeping in mind the replacement of the aws-auth configmap with a CRD, see

• proposal https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/79
• PR https://github.com/kubernetes-sigs/aws-iam-authenticator/pull/116

which will have single role mappings as custom objects named iamidentitymapping, I would suggest to use it as a first-class object with our verbs

eksctl get iamidentitymapping [arn]
eksctl create iamidentitymapping <arn> [--username USER] [--groups GROUP0,GROUP2]
eksctl delete iamidentitymapping <arn>

Some remarks

• aws-iam-authenticator server code currently uses a map with the role ARN as key and won't merge any settings for duplicate arns but just override: https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/c2d2884d23a3bc04fa8cc4d5b032022b38469104/pkg/server/server.go#L167-L174, as far as I can tell that is also the case in the CRD (canonicalARN is the key) [@christopherhein can you confirm?]
• users might have duplicate arns in their aws-auth and as such eksctl <get|delete> iamidentitymapping needs to deal with this (see #544)
• adding/removing accounts is intentionally left out as it is still open where that moves to, it currently is still in aws-auth.mapAccounts (https://github.com/kubernetes-sigs/aws-iam-authenticator/pull/116/files#diff-786be668b558e47d16aef0627155a45bR109) but seems to might find a spot as part of an iamidentitymapping? We'll see and I suggest to tackle this in a second step.
• with the CRD proposal, each entry will also gain a unique Kubernetes resource name, and manipulation could take additional optional parameters [--name NAME --namespace NS] which override the default namespace of kube-system and a generated name.
• flags might benefit from being renamed from --update-auth-configmap to --update-iamidentitymapping or similar

[christopherhein]

@rndstr correct as of now it uses canonicalARN but that is autogenerated for you and stored in the Status all that is necessary is adding username, arn, groups.

Couple things to to note, these are cluster wide resources so namespacing shouldn't be taken into consideration since they only provide authentication not authorization.

mapAccounts hasn't been moved over but you can assume this could be in the future to iamaccountmappings for example.