![]() This authentication configuration is equivalent to the following command aws -region us-east-2 eks get-token -cluster-name dev.my-eks-cluster This way, the kubectl command knows how to authenticate to EKS using the aws-iam-authenticator users: - name: arn:aws:eks:us-east-2:123456789123:cluster/dev.my-eks-cluster user: exec: apiVersion: /v1alpha1 args: -region - us-east-2 - eks - get-token -cluster-name - dev.my-eks-cluster command: aws env: null The way that kubectl (and other Kubernetes operations) authenticate to the cluster is using the configuration described in. After some brainstorming, we assumed that the way aws-iam-authenticator works on our dev machines allows it to assume a role on the fly, and only for Kubernetes-related operations. A common workaround is to use AWS profiles, but this also requires changing the profile before accessing the cluster. The main downside of this solution is that R&D team members must assume the every time they want to interact with the cluster. ![]() Create a policy that allows assuming the role and attach it to your R&D group.Add the role ARN under the mapRoles section of aws-auth.yaml.Create a policy that allows it to manage EKS and attach it to the role.GitHub - How to use IAM Groups?Īfter comparing the different options, we decided to use the most robust solution we found, which is the “assume role” method.GitHub - Can I not add an IAM group to my ConfigMap?.Therefore, it is not possible to define an IAM group for RBAC using standard methods.įurthermore, we found multiple open issues on GitHub asking for help with the same issue: We have built a full format specification based on the implementation - aws-auth-specification.yamlĪs you can see, aws-auth supports three IAM entities mapAccounts, mapUsers and, mapRoles but none of them allow us to map an IAM group. So we read the implementation of aws-iam-authenticator to find alternative solutions. We conducted comprehensive research to verify this fact, and we found that there is no official documentation on the full format specification of aws-auth.yaml. This is an example of aws-auth.yaml file:Īccording to AWS official documentation, aws-auth.yaml doesn’t support IAM groups translation to RBAC. Kubernetes RBAC is not aware of IAM identities.ĪWS EKS uses a specific ConfigMap named aws-auth to manage the AWS Roles and AWS Users who are allowed to connect and manage the cluster (or namespace).Kubernetes RBAC uses these translated identities to enforce permissions to different resources.Each IAM identity is mapped to a Kubernetes username or added to a group.This is achieved by token authentication webhook.Īws-iam-authenticator translates the authenticated identity to a Kubernetes RBAC identity.The general idea is:Īws-iam-authenticator authenticates an IAM identity. Now that we’ve finished our overview of Kubernetes RBAC, let’s dive right in and see how it integrates with AWS IAM. If you’re still not sure about the terminology, Check out Kubernetes RBAC docs for further reading. Since this isn’t really a “Getting started with RBAC” kind of post. Kubernetes Role - A set of permissions for a namespace.Kubernetes's access control naming convention is similar to AWS IAM, so make sure you don't confuse the two. If you are familiar with Kubernetes RBAC, you can go ahead and jump to EKS RBAC Integration with IAM ![]() ![]() Our solution utilizes an IAM role to authenticate the user group automatically and transparently when kubectl is being used.There is no standardized method for providing IAM group access to an EKS cluster or namespace.Authentication - A ConfigMap named aws-auth which is under the kube-system namespace.Authorization - A RoleBinding or a ClusterRoleBinding.There are two configurations required in order to define authentication and authorization:.EKS is configured to use aws-iam-authenticator which allows Kubernetes to integrate with AWS IAM.Authentication can be done in multiple methods.Kubernetes has 2 main methods for authorization:.The time invested in managing our EKS permissions model grew significantly, encouraging us to seek out a comprehensive and sustainable solution to this problem. Growing pains are hard.Īt Grip, we encountered similar frustrations with managing our EKS cluster permissions due to our growing number of engineers and the increasing complexity of our systems. Your organization is growing, apps are succeeding, and your engineering team has tripled-now, manage your Amazon Kubernetes Service (EKS) and permissions for an expansive team of non-stop complexity. ![]()
0 Comments
Leave a Reply. |