{"id":3808,"date":"2021-08-17T14:17:06","date_gmt":"2021-08-17T20:17:06","guid":{"rendered":"http:\/\/benincosa.com\/?p=3808"},"modified":"2021-08-17T14:17:06","modified_gmt":"2021-08-17T20:17:06","slug":"eks-additional-users","status":"publish","type":"post","link":"https:\/\/benincosa.com\/?p=3808","title":{"rendered":"EKS Additional users"},"content":{"rendered":"\n

In our EKS Kubernetes cluster we want multiple AWS users to be able to use the kubectl<\/code> command to examine resources and for now, they can even have admin access to a few select groups. <\/p>\n\n\n\n

The way I’ve always done this in the past is I create new stanza in the aws-auth<\/code> configMap in the kube-system<\/code> namespace. This is how AWS tells you how to do it in their documentation<\/a>. <\/p>\n\n\n\n

The problem with this is you are modifying an obscure file and most people in administering AWS can’t really see this. Today I’ve been trying out roles instead to see if I can get better results. I used some documentation on nextlinklabs.com<\/a> but most of the commands didn’t work for me so I thought they wouldn’t work for most people either. So here goes. <\/p>\n\n\n\n

1. Create a new role<\/h3>\n\n\n\n

This role will be the role people will assume when they want to access Kubernetes. My role looks as follows: <\/p>\n\n\n\n

{\n    \"Role\": {\n        \"Path\": \"\/\",\n        \"RoleName\": \"eks-admin-role\",\n        \"RoleId\": \"XXX\",\n        \"Arn\": \"arn:aws:iam::XXXXXX:role\/eks-admin-role\",\n        \"CreateDate\": \"2021-08-17T01:00:58+00:00\",\n        \"AssumeRolePolicyDocument\": {\n            \"Version\": \"2012-10-17\",\n            \"Statement\": [\n                {\n                    \"Effect\": \"Allow\",\n                    \"Principal\": {\n                        \"AWS\": [\n                            \"arn:aws:iam::XXXX:user\/vallard\",\n                            \"arn:aws:iam::XXXX:user\/test\"\n                        ]\n                    },\n                    \"Action\": \"sts:AssumeRole\",\n                    \"Condition\": {}\n                }\n            ]\n        },\n        \"MaxSessionDuration\": 3600,\n        \"RoleLastUsed\": {\n            \"LastUsedDate\": \"2021-08-17T19:30:56+00:00\",\n            \"Region\": \"us-west-2\"\n        }\n    }\n}<\/code><\/pre>\n\n\n\n
Notice that I need to put all the users in this role that I would otherwise have put in the aws-auth<\/code> configMap.  I was hoping I could just put the groups, but unless I’m using something a little more fancy than AWS user groups, I’m not able to do this. <\/p>\n\n\n\n
2. Allow Users to Assume the Role<\/h3>\n\n\n\n
I created another policy that I add to the users so they can actually assume the role.  It looks as follows: <\/p>\n\n\n\n
{\n    \"Policy\": {\n        \"PolicyName\": \"eks-admin-assume-role-policy\",\n        \"PolicyId\": \"XXXX\",\n        \"Arn\": \"arn:aws:iam::XXXX:policy\/eks-admin-assume-role-policy\",\n        \"Path\": \"\/\",\n        \"DefaultVersionId\": \"v1\",\n        \"AttachmentCount\": 0,\n        \"PermissionsBoundaryUsageCount\": 0,\n        \"IsAttachable\": true,\n        \"CreateDate\": \"2021-08-17T01:10:21+00:00\",\n        \"UpdateDate\": \"2021-08-17T01:10:21+00:00\",\n        \"Tags\": []\n    }\n}<\/code><\/pre>\n\n\n\n
With the permissions set as: <\/p>\n\n\n\n
{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Sid\": \"AllowAssumeOrganizationAccountRole\",\n            \"Effect\": \"Allow\",\n            \"Action\": \"sts:AssumeRole\",\n            \"Resource\": \"arn:aws:iam::XXXX:role\/eks-admin-role\"\n        }\n    ]\n}<\/code><\/pre>\n\n\n\n
Now, we attach this permission to a group that we want to have EKS permissions and assign the user to this group. <\/p>\n\n\n\n
3. Update Kubernetes aws-auth<\/code><\/h3>\n\n\n\n
Now we need to add this role to our list of roles in aws-auth<\/code> configMap.  This is done with: <\/p>\n\n\n\n
kubectl edit cm\/aws-auth -n kube-system<\/code><\/pre>\n\n\n\n
And we simply add our new role to this.  It now looks as follows: <\/p>\n\n\n\n
apiVersion: v1\ndata:\n  mapRoles: \n   - groups: \n     - system:bootstrappers  \n     - system:nodes\n     rolearn: arn:aws:iam::XXXX:role\/wg_eks_node_role_stage\n     username: system:node:{{EC2PrivateDNSName}}\n   - groups:  \n     - system:masters\n     rolearn: arn:aws:iam::XXXX:role\/eks-admin-role\n     username: eks-admin\nkind: ConfigMap\nmetadata:\n  creationTimestamp: \"2020-04-16T17:44:52Z\"\n  name: aws-auth\n  namespace: kube-system<\/code><\/pre>\n\n\n\n
Now this new role has access to the Kubernetes cluster using the systems:masters group, meaning it can do everything on Kubernetes. <\/p>\n\n\n\n
4. Fix ~\/.kube\/config file to use role<\/h3>\n\n\n\n
Lastly, we add some arguments to make our kubeclt<\/code> commands work correctly. <\/p>\n\n\n\n
- name: arn:aws:eks:us-west-2:XXXX:cluster\/eks-cluster\n  user:\n    exec:\n      apiVersion: client.authentication.k8s.io\/v1alpha1\n      args:\n      - --region\n      - us-west-2\n      - eks\n      - get-token\n      - --cluster-name\n      - eks-stage\n      - --role\n      - arn:aws:iam::XXXX:role\/eks-admin-role\n      command: aws\n      env:\n      - name: AWS_PROFILE\n        value: testro\n      provideClusterInfo: false<\/code><\/pre>\n\n\n\n
This seems to work, but to throw one more wrench into the problem, our user must use MFA when connecting to the CLI of our cluster.  So to make this happen, I have to run a special script to first get my CLI authorized with MFA.  Then I can finally run kubectl<\/code> commands!<\/p>\n","protected":false},"excerpt":{"rendered":"
In our EKS Kubernetes cluster we want multiple AWS users to be able to use the kubectl command to examine resources and for now, they can even have admin access to a few select groups. The way I’ve always done this in the past is I create new stanza in the aws-auth configMap in the…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[957],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/posts\/3808"}],"collection":[{"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/benincosa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3808"}],"version-history":[{"count":1,"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/posts\/3808\/revisions"}],"predecessor-version":[{"id":3809,"href":"https:\/\/benincosa.com\/index.php?rest_route=\/wp\/v2\/posts\/3808\/revisions\/3809"}],"wp:attachment":[{"href":"https:\/\/benincosa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3808"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/benincosa.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3808"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/benincosa.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3808"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}