Veeam Kasten for Kubernetes integrates with whatever authentication mechanism customers use to access 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 Veeam Kasten for Kubernetes 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 created by Veeam Kasten for Kubernetes using a ClusterRoleBinding or RoleBinding.
When the user invokes kubectl to access the cluster, kubectl contacts 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.
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 command:
In the example 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:basic
In the example 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
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case