How is the "cluster creator" user of an AWS EKS cluster mapped to the "system:masters" RBAC group?

I'm trying to understand how are managed RBAC authorizations for the first user that create an EKS cluster within AWS.
Or in other words : How is the cluster creator mapped to the "system:masters" group within RBAC ?

I know this doc states : "When you create an Amazon EKS cluster, the IAM entity user or role, such as a federated user that creates the cluster, is automatically granted system:masters permissions in the cluster's RBAC configuration."
And I understand how clusterrole cluster-admin and clusterrolebinding cluster-admin grants full admin rights to any members of the "system:masters" group.

What I can't figure out is how/where is the cluster creator user mapped to this group ? (the "automatically granted" part of the doc)

PS: I know that to add additionnal user/roles I'm supposed to use the aws-auth configmap, but this first user is not defined here and still has access to cluster.

If anyone can enlighten me please ?

Thanks in advance!

For the record I'm using a kubernetes 1.18 EKS cluster that was built with terraform via the community module here :

module "cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "13.2.1"

  cluster_version = "1.18"
  cluster_name    = "memorandom-${local.id}"
  vpc_id          = module.vpc.vpc_id
  subnets         = module.vpc.private_subnets

  write_kubeconfig = false
  manage_aws_auth  = true

  worker_groups = [
    {
      instance_type = "t3.medium"
      asg_max_size  = 3
      key_name      = "pbenefice"
    }
  ]

  tags = local.tags
}

So I reached for AWS Support on this topic. And to summarize the answer was : "Most of what you are asking about is confidential information and cannot be disclosed.".

I paste the full reply here :

Thanks for reaching out to AWS Premium Support. My name is * and I understand you're curious about the implementation details of the cluster creator's being part of the system:masters group.

Most of what you are asking about is confidential information and cannot be disclosed.

However, I can tell you that the EKS Control Plane has an Authenticator component. You can enable logs for this as described here [1].

Personally, I like to think of that "automatically granted" part of the docs as an imaginary, read-only permanent object under the mapUsers: section of the aws-auth configmap. Imaginary because it's not implemented in the aws-auth configmap, but the permissions it is granted are the same as if it were there. I've created an imaginary cluster-creator user object in the example below [2] that shows the effective implementation

[1]: Amazon EKS control plane logging - https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

[2]: Example aws-auth configmap

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    # The way EKS currently bootstraps your cluster permissions, you can think of the cluster-creator having a
    # read-only permanent entry here - the effective permissions are the same
    - userarn: arn:aws:iam::111122223333:user/cluster-creator
      username: cluster-creator
      groups:
        - system:masters
    # In an actual aws-auth configmap, the cluster-creator entry above isn't there and
    # only the mapUsers below would be shown
    - userarn: arn:aws:iam::111122223333:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

The most important practical considerations regarding the cluster creator RBAC permissions are:

• the IAM entity (user or role) that created the cluster is always going to have admin privileges (system:masters permissions)
• if IAM entity is deleted without other IAM entities being added with the necessary permissions to the aws-auth configmap - you have two options:
  1. you must either recreate the IAM entity with the same name to regain access to your cluster, or
  2. delete the cluster and create a new cluster using a new IAM entity

I know this probably wasn't all the information you'd hoped for, but I hope it helps satisfy part of your curiosity. As I can't go into any real depth to answer your questions, I'll go ahead and resolve your case. I hope you have a wonderful day and please feel free to reach out to us anytime.