Configure EKS clusters to use AWS IAM users/roles for K10 access

Follow this guide to provide appropriate K10 role-based access using AWS IAM users or roles.

Description

K10 integrates with whatever authentication mechanism customers use for access to their Kubernetes clusters. Since EKS natively supports AWS IAM authentication, AWS IAM users/roles can be used to delegate access.

See (Managing Users or IAM Roles for your Cluster) for general instructions on providing appropriate access.

For K10 specifically, this involves updating the aws-auth ConfigMap in the kube-system namespace and mapping the specific IAM user or role to a Kubernetes user or group (e.g. k10-admins) . That Kubernetes user or group can then be bound to one of the Kubernetes roles K10 creates via a ClusterRoleBinding or RoleBinding.

How it works

kubectl

When the user invokes kubectl to access the cluster, kubectl calls into the local aws-iam-authenticator tool to get a Kubernetes bearer token and uses that for authentication. The server side aws-iam-authenticator handles validation and maps the user to the group specified above in aws-creds.

Dashboard access

To access a dashboard for a cluster setup in EKS with token authentication, the user must obtain a token from the command line. This can be done via the aws-iam-authenticator tool by running the $ aws-iam-authenticator token -i <clustername> --token-only command.

Note: For facilitating role-based access for users, K10 leverages Kubernetes ClusterRoles and Bindings. 

Example: IAM user

In the cluster below - the IAM user bob is mapped to the k10:basic group

$ kubectl get configmap aws-auth --namespace kube-system -oyaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::036776340102:role/eksctl-vktest1-nodegroup-vktest1-NodeInstanceRole-WOF6PPR92MA3
      username: system:node:
  mapUsers: |
    - userarn: arn:aws:iam::036776340102:user/bob
      username: bob
      groups:
        - k10:basic
kind: ConfigMap
metadata:
  creationTimestamp: "2019-12-27T22:19:48Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "1890252"
  selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth
  uid: fe65adba-28f6-11ea-a292-0eb842cb8343

The k10:basic group is then provided access that is in the pre-existing k10-basic role by creating the following ClusterRoleBinding

$ kubectl get clusterrolebinding kasten-io-k10-k10-cluster-basic -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2020-01-07T18:26:52Z"
  name: kasten-io-k10-k10-cluster-basic
  resourceVersion: "1890605"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kasten-io-k10-k10-cluster-basic
  uid: 4688cbae-317b-11ea-a292-0eb842cb8343
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-basic
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:tom

Example: IAM role

In the cluster below - the IAM role k10-access is mapped to the k10:admin group

$ kubectl get cm aws-auth -n kube-system -o yaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::036776340102:role/eksctl-pv-eks-1-nodegroup-standar-NodeInstanceRole-33IF4JCW7UJ1
      username: system:node:
    - groups:
      - k10:admin
      rolearn: arn:aws:iam::036776340102:role/pv-iam-role-k10-access
      username: k10
kind: ConfigMap
metadata:
  creationTimestamp: "2020-01-14T00:01:03Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "2631996"
  selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth
  uid: f4472c09-3660-11ea-bf0c-06020ce34614

The k10:admin group is then provided access that is in the pre-existing k10-admin role by creating the following ClusterRoleBinding

$ kubectl get clusterrolebinding kasten-io-k10-k10-cluster-roleadmin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2020-01-31T06:45:30Z"
  name: kasten-io-k10-k10-cluster-roleadmin
  resourceVersion: "2633974"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kasten-io-k10-k10-cluster-roleadmin
  uid: 45d8a3e1-43f5-11ea-bf0c-06020ce34614
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:admin

Tip: Every K10 deployment comes installed with three default K10 ClusterRoles: k10-admin, k10-basic, and k10-dashboard-view, which can be customized.

More details can be found in the K10 documentation here.