Add command eksctl utils aws-auth

[rndstr]

Adds the command

eksctl utils aws-auth --name=<name> [--add-admin-role=<arn>] [--remove-role=<arn>] [--add-account=<number>] [--remove-account=<number>]

to allow modifying the kube-system/aws-auth object which is a mapping from IAM entities to Kubernetes groups.

[mumoshu]

Hey! I think this is great even at this point.

The benefit of this improvement and the addition of addAccount() is that (to me) this opens up possibility to manage additional mapRoles and mapAccounts in our ClusterConfig.

Perhaps your original motivation could be either to:

• implement eksctl utils aws-auth [map|unmap] [account --id AWS_ACCOUNT_ID|role --arn ROLE_ARN --username USERNAME --groups GROUP1,GROUP2] on top of this, or
• enhance ClusterConfig and add eksctl utils apply-aws-auth -f cluster.yaml to update the aws-auth configmap according to the mappings in ClusterConfig.

If that's the case, I would have thought that I liked the latter, but WDYT?

[rndstr]

@mumoshu thanks for the suggestions. this PR is motivated by the former (sorry for scarce PR description). I briefly went over this with @errordeveloper beforehand and we were talking about a separate command.

What I'm personally looking for is the functions to simplify adding/removing roles/accounts, so the command is secondary to me.

I prefer your suggestion over mine (dislike the verbs in my args), so I'll change this.

[rndstr]

@mumoshu wdyt about omitting the --id and --arn flags and use them as args instead? eksctl utils aws-auth [map|unmap] [account AWS_ACCOUNT_ID|role ROLE_ARN --username USERNAME --groups GROUP1,GROUP2]

I reckon an argument against this would be the convention to use the first arg as cluster name seen in most commands.

[errordeveloper]

Looks great overall, just a few nits :)

[errordeveloper]

@rndstr I don't mind merging it as is, and we can have a separate conversation about the CLI design.

I think it would make sense to consider this:

eksctl auth <add-account|remove-account> AWS_ACCOUNT_ID
eksctl auth <add-role|remove-role> ROLE_ARN --username USERNAME --groups GROUP1,GROUP2

But it also seems plausible to provide full create/get/delete, and perhaps we should think about treating it as a first-class resource, i.e.:

eksctl <create|get|delete> account
eksctl <create|get|delete> role

I'm not sure what's best, also the underlying details may change as EKS may finally move to a CRD instead of this configmap... so whatever we do now may have to change sooner or later. I'd really vote for keeping it as is for now.

[rndstr]

@errordeveloper what about

eksctl <create|get|delete> auth-account
eksctl <create|get|delete> auth-role

which elaborates on what kind of account or role this is.

i first preferred

eksctl auth <add-account|remove-account> AWS_ACCOUNT_ID
eksctl auth <add-role|remove-role> ROLE_ARN --username USERNAME --groups GROUP1,GROUP2

but I think a command to display the current version would be nice too, which would be eksctl auth get which screws over the eksctl <verb> <subject> consistency.

[errordeveloper]

On Tue, 12 Mar 2019, 9:20 pm Roli Schilter, ***@***.***> wrote: @errordeveloper <https://github.com/errordeveloper> what about eksctl <create|get|delete> auth-account eksctl <create|get|delete> auth-role which elaborates on what kind of account or role this is.

Yes, but it is odd because it breaks out a narrow concept of what is a single object inside the cluster into several new concepts. Most resources we have at the moment are the opposite, e.g. a cluster brings together great many things, and so does a nodegroup (albeit to a lesser degree). And that config map always gets updated, so it only naturally maps to the update verb, maybe get and update verbs are what we would actually want here? We do have verbs that are used with just certain resources, most notably 'eksctl scale ng'. Perhaps when we add IAM as a resource (along with VPC), this could be somehow part of that, or perhaps it will become clearer when we have 'eksclt create|get|delete cluster-iam|nodegroup-iam' (or whatever we decide to call it). I would rather merge this PR as is and continue design discussion elsewhere :)

[errordeveloper]

So my conclusion is that we either move along, merge it and review later on, or move current implementation to 'eksctl update iam-auth-bindings' (considering that other '*iam*' resources will materialise in the future). Feel free to keep the flags as they are. If you feel like that would be the right thing, 'eksclt get iam-auth-bindings' would be nice to have, of course. On Tue, 12 Mar 2019, 11:53 pm Ilya Dmitrichenko, <[email protected]> wrote:

…

On Tue, 12 Mar 2019, 9:20 pm Roli Schilter, ***@***.***> wrote: > @errordeveloper <https://github.com/errordeveloper> what about > > eksctl <create|get|delete> auth-account > eksctl <create|get|delete> auth-role > > which elaborates on what kind of account or role this is. > Yes, it is odd cause it breaks out a narrow concept of what is a single object inside the cluster into several new concepts. Most resources we have at the moment are the opposite, e.g. a cluster brings together great many things, and so does a nodegroup (albeit to a lesser degree). Perhaps when we add IAM as a resource (along with VPC), this could be somehow part of that, or perhaps it will become clearer when we have 'eksclt create|get|delete cluster-iam|nodegroup-iam' (or whatever we decide to call it). I would rather merge this PR as is and continue design discussion elsewhere :)

[rndstr]

@errordeveloper created #625 and removed the command itself for now

[errordeveloper]

hm... integration tests failed for me, seems like it's to do with this change?

2019-03-13T18:48:40Z [▶]  done after 4m22.7808778s of waiting for CloudFormation stack "eksctl-exciting-mushroom-1552501999-nodegroup-ng-0" to reach "CREATE_COMPLETE" status
2019-03-13T18:48:41Z [▶]  processing stack outputs
2019-03-13T18:48:41Z [▶]  task 0 returned without errors
2019-03-13T18:48:41Z [✔]  all EKS cluster resource for "exciting-mushroom-1552501999" had been created
2019-03-13T18:48:41Z [▶]  merging kubeconfig files
2019-03-13T18:48:41Z [▶]  setting current-context to [email protected]
2019-03-13T18:48:41Z [✔]  saved kubeconfig as "/tmp/kubeconfig"
2019-03-13T18:48:42Z [▶]  aws-auth = {
  TypeMeta: {
    Kind: "",
    APIVersion: ""
  },
  ObjectMeta: {
    Name: "",
    GenerateName: "",
    Namespace: "",
    SelfLink: "",
    UID: ,
    ResourceVersion: "",
    Generation: 0,
    CreationTimestamp: {
      Time: 0001-01-01 00:00:00 +0000 UTC
    },
    ClusterName: ""
  }
}
2019-03-13T18:48:42Z [ℹ]  adding role "arn:aws:iam::376248598259:role/eksctl-exciting-mushroom-15525019-NodeInstanceRole-5EUF1ZLNQ3SG" to auth ConfigMap
2019-03-13T18:48:42Z [✖]  saving auth ConfigMap: ConfigMap "" is invalid: metadata.name: Required value: name or generateName is required

@rndstr wdyt?