This Module can be used to manage the mapping of AWS IAM roles and users to Kubernetes RBAC groups for finer grained
access control of your EKS Cluster.
This Module only manages the mapping between IAM roles and Kubernetes RBAC groups. This Module does not create, modify,
or configure either roles. We recommend managing them in a separate Terraform template in the context of your needs,
that are then provided as inputs to this module.
How do you use this module?
See the root README for instructions on using Terraform modules.
See variables.tf for all the variables you can set on this module.
See outputs.tf for all the variables that are outputed by this module.
What is Kubernetes Role Based Access Control (RBAC)?
Role Based Access Control (RBAC) is a method to regulate
access to resources based on the role that individual users assume in an organization. Kubernetes allows you to define
roles in the system that individual users inherit, and explicitly grant permissions to resources within the system to
those roles. The Control Plane will then honor those permissions when accessing the resources on Kubernetes on behalf of
clients such as kubectl. When combined with namespaces, you can implement sophisticated control schemes that limit the
access of resources across the roles in your organization.
The RBAC system is managed using ClusterRole and ClusterRoleBinding resources (or Role and RoleBinding resources
if restricting to a single namespace). The ClusterRole (or Role) object defines a role in the Kubernetes system that
has explicit permissions on what it can and cannot do. These roles are then bound to users and groups using the
ClusterRoleBinding (or RoleBinding) resource. An important thing to note here is that you do not explicitly create
users and groups using RBAC, and instead rely on the authentication system to implicitly create these entities.
AWS IAM role is AWS's implementation of RBAC. Users
and clients authenticate to AWS to assume an IAM role, that has a set of permissions that grant or deny access to
various resources within AWS. Unlike users, IAM roles do not have long standing credentials associated with them.
Instead, a user uses the AWS API to assume a role, which will issue temporary credentials that can be used to access the
AWS resources as the assumed role. Like the roles in the Kubernetes RBAC implementation, you can configure the roles to have
as much or as little permissions as necessary when accessing resources in the AWS system.
This Module provides code for you to manage the mapping between AWS IAM roles and Kubernetes RBAC roles so that you can
maintain a consistent set of mappings between the two systems. This works hand in hand with the EKS authentication
system, providing the information to Kubernetes to resolve the user to the right RBAC group based on the provided IAM role credentials.
Examples
Restricting specific actions
Suppose that you are setting up your EKS cluster for your organization that has an ops team and a dev team. Suppose
further that your organization would like to restrict access to your dev team so that they can only list and update
existing Pods, but can not create new ones, while the ops team is able to manage all resources in your Kubernetes
cluster.
To support this, we need to first define the roles in Kubernetes that map to the explicit permissions granted to each
team. For the ops team in Kubernetes, since we want to grant them admin level privileges on the cluster, we can use the
default system:admin group that will already obtain those permissions. For the dev group however, there is no
default group and role that fits our needs, so we need to define a new ClusterRole and bind it to the dev group. To do
this, we will first define the ClusterRole resource using the RBAC API:
This creates a new role dev that allows the role to get, list, and update Pods in any namespace in the cluster. We can
apply this on the cluster using kubectl:
kubectl apply -f dev-role.yml
We then need to bind this to the dev group using a ClusterRoleMapping resource:
This config binds the ClusterRole named dev to the Group named dev. Like the ClusterRole config, we can apply
this on the cluster using kubectl:
kubectl apply -f dev-role-binding.yml
Now that we have the two roles and bindings in the system, we need some way for users in the ops and dev teams to inherit
the roles. This is done implicitly by mapping their authentication credentials to their respective groups. In EKS,
authentication is handled by IAM, which means that we need to tell Kubernetes to map their IAM credentials to their
respective groups. We will use this Module to do exactly that.
This Module takes as input a mapping between IAM roles and RBAC groups as part of the iam_role_to_rbac_group_mapping
input variable. In this example, we will assume that members of the ops team access the cluster by assuming the ops
IAM role and members of the dev team access the cluster by assuming the dev IAM role, so we will map these to their
respective groups in Kubernetes:
When you terraform apply the above code, the Module will configure Kubernetes to resolve the provided AWS IAM roles to
the specified RBAC groups when fulfilling client requests. In this case, any kubectl authentications using the dev
IAM role will resolve to the dev Kubernetes RBAC group, while any authentications using the ops IAM role will resolve
to the system:admin Kubernetes RBAC group. The dev team will then implicitly inherit the devClusterRole based
on the ClusterRoleBinding that binds that role to the dev group.
Important: Note that we did not need to define the dev group explicitly in Kubernetes. This is automatically
handled by the authentication system. In Kubernetes, the group is implicitly defined as part of defining a user entity
that can map to it. As such, it is important to take care to avoid typos here to ensure that the string you use for the
group here matches any groups referenced in the role bindings.
Restricting by namespace
In this example, suppose that you are setting up a dev EKS cluster for your dev team that is organized into multiple
subteams working on different products. In this scenario, you want to give members of the dev team full access to deploy
and manage their applications, including deleting resources. However, you may want to implement controls so that teams
can only manage their own resources, and not others' resources.
To support this, you would use Kubernetes
namespaces to partition your Kubernetes
cluster. Namespaces allow you to divide your resources into logical groups on the cluster. By utilizing namespaces, you
can grant teams full access to resources launched in their own namespace, but restrict access to resources in other
namespaces.
To implement this on your EKS cluster, you would first need to create namespaces for each team. For this example, we
will assume there are two dev teams in the organization: api and backend. So we will create a namespace for each
team:
This will create two namespaces: one named apiteam and one named backendteam. We can apply this on the cluster using
kubectl:
kubectl apply -f namespaces.yml
Next, we need to create RBAC roles in Kubernetes that grant access to each of the namespaces, but not others. To do this
we will rely on the Role resource, instead of the ClusterRole resource because we want to scope the permissions to a
particular namespace:
This will create two roles in the Kubernetes cluster: apiteam-full-access and backendteam-full-access, each giving
full access to all resources in the respective namespaces. Like the YAML file for the namespaces, you can apply this on
the cluster using kubectl:
kubectl apply -f roles.yml
To allow authenticating entities to be able to inherit these roles, we need to map these to a group. We can do that by
defining RoleBinding resources:
These two resources bind the apiteam to the apiteam-full-access role and the backendteam to the
backendteam-full-access role so that any client that maps to those groups will inherit the right permissions. We can
apply this to the cluster using kubectl:
kubectl apply -f role-bindings.yml
Now that we have the namespaces, the roles, and the bindings in the system, we need to create the AWS IAM roles that map
to each team and tell Kubernetes to map the AWS IAM role to the proper RBAC role when authenticating the client. We will
assume that the IAM roles already exist (named ApiDeveloper and BackendDeveloper). To map the IAM roles to the RBAC
groups, we will use this Module. This Module takes as input a mapping between IAM roles and RBAC roles as part of the
iam_role_to_rbac_group_mapping input variable:
When you terraform apply the above code, the Module will configure Kubernetes to resolve the provided AWS IAM roles to
the specified RBAC groups when fulfilling client requests. In this case, any kubectl authentications using the
ApiDeveloper IAM role will resolve to the apiteam Kubernetes RBAC group, while any authentications using the
BackendDeveloper IAM role will resolve to the backendteam Kubernetes RBAC group. In this way, the
developers who authenticate as ApiDeveloper will only be able to access the apiteam namespace in the Kubernetes
cluster, while the developers who authenticate as BackendDeveloper will only be able to access the backendteam
namespace.
Important: Note that we did not need to define the apiteam and backendteam group explicitly in Kubernetes. This
is automatically handled by the authentication system. In Kubernetes, the group is implicitly defined as part of
defining a user entity that can map to it. As such, it is important to take care to avoid typos here to ensure that the
string you use for the group here matches any groups referenced in the role bindings.
Why not use a Helm Chart?
This Module cannot be implemented as a helm chart due to the functionality of the ConfigMap being generated here. In
EKS, the worker nodes also use an IAM role to authenticate against the EKS Control Plane. As such, the worker nodes rely
on the mapping from the aws-auth ConfigMap generated by this module to be able to successfully register to the EKS
cluster as a worker node.
To use Helm, the Kubernetes cluster must be running the Tiller (Helm Server) Pods on the cluster. However, to run the
Tiller Pods, the cluster must have worker nodes online and available. As such, we have a chicken and egg situation,
where to use Helm we need to have worker nodes, which need the aws-auth ConfigMap, which needs Helm.
To avoid this cyclic dependency, we implement this module using the kubernetes provider which will use kubectl under
the hood. The cluster requirement for a working kubectl is the EKS control plane, which will be available without the
ConfigMap and as such does not have the cyclic dependency problem of Helm.
Questions? Ask away.
We're here to talk about our services, answer any questions, give advice, or just to chat.
{"treedata":{"name":"root","toggled":true,"children":[{"name":".circleci","children":[{"name":"config.yml","path":".circleci/config.yml","sha":"cd0f759ae90af4380a46377f990df626a9b4384f"}]},{"name":".gitignore","path":".gitignore","sha":"7f6cf4bc746bbfd6da4c7a21dbcf1a2296aa0c10"},{"name":".pre-commit-config.yaml","path":".pre-commit-config.yaml","sha":"b008949ef10a7bad93ab93e8821da77577a30c5c"},{"name":"CODEOWNERS","path":"CODEOWNERS","sha":"ecbeaab263c59e955b621268f161059633041e3d"},{"name":"CONTRIBUTING.md","path":"CONTRIBUTING.md","sha":"a7cc7bd94443c252390564fa988755dbbe80d87d"},{"name":"GRUNTWORK_PHILOSOPHY.md","path":"GRUNTWORK_PHILOSOPHY.md","sha":"02d9873a74c99fe6d9b6b26bd9f8eb4a7a699c32"},{"name":"LICENSE.md","path":"LICENSE.md","sha":"a2cf01ecdd725fddd718ab91c80c115882c94f3c"},{"name":"README.adoc","path":"README.adoc","sha":"1489d0ec36ab170c76f9a351fef8dc19e8e39d4a"},{"name":"_docs","children":[{"name":"eks-architecture.png","path":"_docs/eks-architecture.png","sha":"b4c9c46f88ed465c5575e915af54ad9920b56941"},{"name":"eks-icon.png","path":"_docs/eks-icon.png","sha":"83a29dc46e7bc6234ba5bb825e8ae283c56229a0"}]},{"name":"core-concepts.md","path":"core-concepts.md","sha":"3c504a547fc55ecff5536141534a32ed8a4a4ae7"},{"name":"examples","children":[{"name":"README.md","path":"examples/README.md","sha":"a70f3adc0c888e07b0b03cb32fbd156547c354da"},{"name":"eks-cluster-managed-workers","children":[{"name":"README.md","path":"examples/eks-cluster-managed-workers/README.md","sha":"21acaeb73c1d8a1819480bc7a8d1c35b8fa69081"},{"name":"dependencies.tf","path":"examples/eks-cluster-managed-workers/dependencies.tf","sha":"a37b6da5f0bc9833de95bcf7f489b6cc588bfc75"},{"name":"main.tf","path":"examples/eks-cluster-managed-workers/main.tf","sha":"3ff9b3d364042cf2f3043af04a9fdc89d560b382"},{"name":"outputs.tf","path":"examples/eks-cluster-managed-workers/outputs.tf","sha":"431bebd71e3f9d5c299c1740ba16b2eef717cbf0"},{"name":"variables.tf","path":"examples/eks-cluster-managed-workers/variables.tf","sha":"bb99c8021ead4a0bfc8ff2d4439af9b11ee4a08e"}]},{"name":"eks-cluster-with-iam-role-mappings","children":[{"name":"README.md","path":"examples/eks-cluster-with-iam-role-mappings/README.md","sha":"6479e81678f2e08df477d467f2124f5dc53e9e53"},{"name":"dependencies.tf","path":"examples/eks-cluster-with-iam-role-mappings/dependencies.tf","sha":"239c10bcbb3db0b79aadac5b92cf72a74fccc635"},{"name":"main.tf","path":"examples/eks-cluster-with-iam-role-mappings/main.tf","sha":"67a8fce50550b0410b438a20020e758aa799f623"},{"name":"outputs.tf","path":"examples/eks-cluster-with-iam-role-mappings/outputs.tf","sha":"3876c30890ffef1726d533a869c23e66fa244e6c"},{"name":"user-data","children":[{"name":"user-data.sh","path":"examples/eks-cluster-with-iam-role-mappings/user-data/user-data.sh","sha":"b10c34bfe4c9d10101472b47edbc3b7dff42a88e"}]},{"name":"variables.tf","path":"examples/eks-cluster-with-iam-role-mappings/variables.tf","sha":"d65401e958df0e8e65b4b2df855f6f386e04971b"}]},{"name":"eks-cluster-with-supporting-services","children":[{"name":"README.md","path":"examples/eks-cluster-with-supporting-services/README.md","sha":"e397bd96f549146ad75369bb248fb564a617e0fe"},{"name":"core-services","children":[{"name":"README.md","path":"examples/eks-cluster-with-supporting-services/core-services/README.md","sha":"c1eb41e7cc60a67d29ef846daf3b2e974ca59e6e"},{"name":"dependencies.tf","path":"examples/eks-cluster-with-supporting-services/core-services/dependencies.tf","sha":"0176248910eed450c12b54d10e3d74c8702c17ca"},{"name":"main.tf","path":"examples/eks-cluster-with-supporting-services/core-services/main.tf","sha":"72e1ed45f9367af0dd9746b789ec09cab323a3f9"},{"name":"outputs.tf","path":"examples/eks-cluster-with-supporting-services/core-services/outputs.tf","sha":"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"},{"name":"variables.tf","path":"examples/eks-cluster-with-supporting-services/core-services/variables.tf","sha":"8682297d51f2751dbe446d79a50d18d3104ec6fe"}]},{"name":"eks-cluster","children":[{"name":"README.md","path":"examples/eks-cluster-with-supporting-services/eks-cluster/README.md","sha":"8a60a01004a93bbbf2091b730f0207f6dd2cc07e"},{"name":"dependencies.tf","path":"examples/eks-cluster-with-supporting-services/eks-cluster/dependencies.tf","sha":"fdc70a25511df461747927bc6874cff7bc787def"},{"name":"main.tf","path":"examples/eks-cluster-with-supporting-services/eks-cluster/main.tf","sha":"7edf894990ad4a46e08727d9438115bbd8b7f603"},{"name":"outputs.tf","path":"examples/eks-cluster-with-supporting-services/eks-cluster/outputs.tf","sha":"e411d10910a2683f6b62af12c14ac6a7d26374f3"},{"name":"user-data","children":[{"name":"app_worker_user_data.sh","path":"examples/eks-cluster-with-supporting-services/eks-cluster/user-data/app_worker_user_data.sh","sha":"c5fdd13d5bb04f765f1c90e9f12d23c48e94a252"},{"name":"core_worker_user_data.sh","path":"examples/eks-cluster-with-supporting-services/eks-cluster/user-data/core_worker_user_data.sh","sha":"0fa26153108b3d030ceeaae777aeb0a7e115404e"}]},{"name":"variables.tf","path":"examples/eks-cluster-with-supporting-services/eks-cluster/variables.tf","sha":"ae89473e21f347e59c6aa09e6bc64ddba1720d71"}]},{"name":"nginx-service","children":[{"name":"README.md","path":"examples/eks-cluster-with-supporting-services/nginx-service/README.md","sha":"0f6649ddb0cbb5aa80a5bc1f3318ea1fd5d0dc35"},{"name":"dependencies.tf","path":"examples/eks-cluster-with-supporting-services/nginx-service/dependencies.tf","sha":"0176248910eed450c12b54d10e3d74c8702c17ca"},{"name":"main.tf","path":"examples/eks-cluster-with-supporting-services/nginx-service/main.tf","sha":"db605685e89d5d8ea0b04ae09d52b4acd815270c"},{"name":"templates","children":[{"name":"values.yaml","path":"examples/eks-cluster-with-supporting-services/nginx-service/templates/values.yaml","sha":"298435e01df9fa495b15d512073c62662d292cd3"}]},{"name":"variables.tf","path":"examples/eks-cluster-with-supporting-services/nginx-service/variables.tf","sha":"36ea6f8a36b19e34dbeeb25ae7e5fcf30c956b0f"}]},{"name":"packer","children":[{"name":"README.md","path":"examples/eks-cluster-with-supporting-services/packer/README.md","sha":"6a974a7fd5da7ac13309d9e0c4aaba7bd8cb46c7"},{"name":"build.json","path":"examples/eks-cluster-with-supporting-services/packer/build.json","sha":"f789255893742da04a572037f9d76bb6236f61e9"}]}]},{"name":"eks-fargate-cluster-with-irsa","children":[{"name":"README.md","path":"examples/eks-fargate-cluster-with-irsa/README.md","sha":"7dfcee13140ca3df3baf9f61e666a45dde71a98a"},{"name":"dependencies.tf","path":"examples/eks-fargate-cluster-with-irsa/dependencies.tf","sha":"438f66c08f411f13a35d477c117346f84c5b642b"},{"name":"main.tf","path":"examples/eks-fargate-cluster-with-irsa/main.tf","sha":"638fbf297c0cdd4bde0b83f7f715c0c80ce56afb"},{"name":"outputs.tf","path":"examples/eks-fargate-cluster-with-irsa/outputs.tf","sha":"f059d7b74ffbfb06a0868d6d0a5d1831c8f45f10"},{"name":"variables.tf","path":"examples/eks-fargate-cluster-with-irsa/variables.tf","sha":"858fa39072856e804644ecaa1162446b49585045"}]},{"name":"eks-fargate-cluster-with-supporting-services","children":[{"name":"README.md","path":"examples/eks-fargate-cluster-with-supporting-services/README.md","sha":"ada00688a7ad6563640e648dfc85df1c05fc93c8"},{"name":"core-services","children":[{"name":"README.md","path":"examples/eks-fargate-cluster-with-supporting-services/core-services/README.md","sha":"cde0ae405e4d73e9e39c67045fb82de8187a673d"},{"name":"dependencies.tf","path":"examples/eks-fargate-cluster-with-supporting-services/core-services/dependencies.tf","sha":"0176248910eed450c12b54d10e3d74c8702c17ca"},{"name":"main.tf","path":"examples/eks-fargate-cluster-with-supporting-services/core-services/main.tf","sha":"b0903866b183a7447ee42c4474c11bbeacaf1320"},{"name":"variables.tf","path":"examples/eks-fargate-cluster-with-supporting-services/core-services/variables.tf","sha":"c63e2fdb8d5aa91830db61224ce75ee814d6fa56"}]},{"name":"eks-cluster","children":[{"name":"dependencies.tf","path":"examples/eks-fargate-cluster-with-supporting-services/eks-cluster/dependencies.tf","sha":"c1fa9e2c0d794ed6a8bf8afe6773d9645ea161d8"},{"name":"main.tf","path":"examples/eks-fargate-cluster-with-supporting-services/eks-cluster/main.tf","sha":"3ee0ca7e71b65d94789ef562f71e2c1074090bdf"},{"name":"outputs.tf","path":"examples/eks-fargate-cluster-with-supporting-services/eks-cluster/outputs.tf","sha":"db0e767fd7ed3a0bcad5628a0c13b6208a442f13"},{"name":"variables.tf","path":"examples/eks-fargate-cluster-with-supporting-services/eks-cluster/variables.tf","sha":"1e0a60dfbf55ce33b088379335725c83d6970cac"}]},{"name":"nginx-service","children":[{"name":"dependencies.tf","path":"examples/eks-fargate-cluster-with-supporting-services/nginx-service/dependencies.tf","sha":"0176248910eed450c12b54d10e3d74c8702c17ca"},{"name":"main.tf","path":"examples/eks-fargate-cluster-with-supporting-services/nginx-service/main.tf","sha":"1ae7751069711726f7c38fafe60d63d0c5f59494"},{"name":"templates","children":[{"name":"values.yaml","path":"examples/eks-fargate-cluster-with-supporting-services/nginx-service/templates/values.yaml","sha":"655914f91177135cb7c5f15b62166cfc82a62a91"}]},{"name":"variables.tf","path":"examples/eks-fargate-cluster-with-supporting-services/nginx-service/variables.tf","sha":"d3c166441cdc556b0839930fbc281b7e8a1bd57f"}]}]},{"name":"eks-fargate-cluster","children":[{"name":"README.md","path":"examples/eks-fargate-cluster/README.md","sha":"df681cdbe945d0592ca57bd3a8eb9ae5d88c2f4a"},{"name":"dependencies.tf","path":"examples/eks-fargate-cluster/dependencies.tf","sha":"438f66c08f411f13a35d477c117346f84c5b642b"},{"name":"main.tf","path":"examples/eks-fargate-cluster/main.tf","sha":"9ec1e5194474d20089a7c1821aa542659cbef2ff"},{"name":"outputs.tf","path":"examples/eks-fargate-cluster/outputs.tf","sha":"5115288e4192921035aba980990103fe4c4b7150"},{"name":"terraform.tfvars.back","path":"examples/eks-fargate-cluster/terraform.tfvars.back","sha":"6cb73f75cc7828c6b3efdc2a9b1787f75ed276d1"},{"name":"user-data","children":[{"name":"user-data.sh","path":"examples/eks-fargate-cluster/user-data/user-data.sh","sha":"b10c34bfe4c9d10101472b47edbc3b7dff42a88e"}]},{"name":"variables.tf","path":"examples/eks-fargate-cluster/variables.tf","sha":"e196669304744fddc35bc16703bc952a5e75898c"}]}]},{"name":"modules","children":[{"name":"eks-alb-ingress-controller-iam-policy","children":[{"name":"README.md","path":"modules/eks-alb-ingress-controller-iam-policy/README.md","sha":"c87be2ee00f8f59403f827303915b5a70c602002"},{"name":"iampolicy.json","path":"modules/eks-alb-ingress-controller-iam-policy/iampolicy.json","sha":"5cba0c1500ee2520d72e8d47b86e318958e4dbc7"},{"name":"main.tf","path":"modules/eks-alb-ingress-controller-iam-policy/main.tf","sha":"a79f5a2e6a0ba72562c5a87182db516d8824ed21"},{"name":"outputs.tf","path":"modules/eks-alb-ingress-controller-iam-policy/outputs.tf","sha":"b551b0bcc6eb1b43bfff1606696566658564cfb4"},{"name":"variables.tf","path":"modules/eks-alb-ingress-controller-iam-policy/variables.tf","sha":"250152e6bfeb02a16bed4151ffc7156636db1bd9"}]},{"name":"eks-alb-ingress-controller","children":[{"name":"README.md","path":"modules/eks-alb-ingress-controller/README.md","sha":"3bfcd0485ea2239eb786564e74c1de0715f23b57"},{"name":"main.tf","path":"modules/eks-alb-ingress-controller/main.tf","sha":"904eefe37cc316b36adbfed59f3c0ebdb218f343"},{"name":"templates","children":[{"name":"node_affinity.yaml","path":"modules/eks-alb-ingress-controller/templates/node_affinity.yaml","sha":"c6eaf8e94fa7c893857cc009df954443239a8fe0"},{"name":"values.yaml","path":"modules/eks-alb-ingress-controller/templates/values.yaml","sha":"9937ba0cbea50640aabca372efedb0e1bdc2ce6d"}]},{"name":"variables.tf","path":"modules/eks-alb-ingress-controller/variables.tf","sha":"0e7c5bdd84bf1835d3cda57a313a2046f310ba23"}]},{"name":"eks-cloudwatch-container-logs","children":[{"name":"README.md","path":"modules/eks-cloudwatch-container-logs/README.md","sha":"83b6cfce471a5b3d0dca1c17b8528d4a3397eae6"},{"name":"main.tf","path":"modules/eks-cloudwatch-container-logs/main.tf","sha":"6827dfece6304e7f439c7bcfb1ccd37c24284c55"},{"name":"outputs.tf","path":"modules/eks-cloudwatch-container-logs/outputs.tf","sha":"7061ed458fec528c8b8b587291f0eccb4324fb72"},{"name":"templates","children":[{"name":"node_affinity.yaml","path":"modules/eks-cloudwatch-container-logs/templates/node_affinity.yaml","sha":"cf47b63d7c2b9699e0ab1e36e9a8dadad3a7f4c0"},{"name":"values.yaml","path":"modules/eks-cloudwatch-container-logs/templates/values.yaml","sha":"bff95a2bcea59db932239c8d197aea76d595bcec"}]},{"name":"variables.tf","path":"modules/eks-cloudwatch-container-logs/variables.tf","sha":"748747e26e3fef8f8a44849c752ba548d8531439"}]},{"name":"eks-cluster-control-plane","children":[{"name":"README.md","path":"modules/eks-cluster-control-plane/README.md","sha":"ceb855c80b54fd83029d40d7f31f282225ab41bf"},{"name":"control_plane_scripts","children":[{"name":"bin","children":[{"name":"control_plane_scripts_py27_env.pex","path":"modules/eks-cluster-control-plane/control_plane_scripts/bin/control_plane_scripts_py27_env.pex","sha":"a02c9440827aac48475673ed80106b8cc1376bb4"},{"name":"control_plane_scripts_py3_env.pex","path":"modules/eks-cluster-control-plane/control_plane_scripts/bin/control_plane_scripts_py3_env.pex","sha":"3b4950866dbf6ad90a029585521aa90ed3e8887c"}]},{"name":"build.sh","path":"modules/eks-cluster-control-plane/control_plane_scripts/build.sh","sha":"33b5e9231babdb0c2c0997b04a964c27b98a4e13"},{"name":"cleanup_cluster_resources","children":[{"name":"__init__.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/cleanup_cluster_resources/__init__.py","sha":"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"},{"name":"global_vars.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/cleanup_cluster_resources/global_vars.py","sha":"47920d25645a8c168f196beb76eb37da60055dd3"},{"name":"main.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/cleanup_cluster_resources/main.py","sha":"21dfb38d1bf8f4d15a03da5e09ae3ba575eb4501"},{"name":"vpc.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/cleanup_cluster_resources/vpc.py","sha":"adaf19fe8e191badfad40513984778d36a059ba5"}]},{"name":"control_plane_scripts_utils","children":[{"name":"__init__.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/control_plane_scripts_utils/__init__.py","sha":"37d050d1afd8ebb0c9d6916cff61fa674e6ac8a3"},{"name":"project_logging.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/control_plane_scripts_utils/project_logging.py","sha":"c29bfb0dfe0a3d4e04aeaabff0b2e58387ccf12b"}]},{"name":"dev_requirements.txt","path":"modules/eks-cluster-control-plane/control_plane_scripts/dev_requirements.txt","sha":"430b91474dc8220624012e70d8c2e43582f17161"},{"name":"requirements.txt","path":"modules/eks-cluster-control-plane/control_plane_scripts/requirements.txt","sha":"0ae8cdb74f4c793658c5dfdd13ce1ec723f7b2a1"},{"name":"upgrade_cluster","children":[{"name":"__init__.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/__init__.py","sha":"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"},{"name":"eks.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/eks.py","sha":"d0aca412ffa983300df0d8926bee8829e148f85e"},{"name":"exceptions.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/exceptions.py","sha":"c35893a0f70e2c0d86dd64b7bce8d092e84355b3"},{"name":"global_vars.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/global_vars.py","sha":"e223eefafed2576c8988a708395d92f6908b3f49"},{"name":"k8s.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/k8s.py","sha":"1194d9dde3ef803b04b4fb50478812ca9beda3b1"},{"name":"k8s_version_map.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/k8s_version_map.py","sha":"f3fa6b6afa0900130f8a672a721645c914815f8c"},{"name":"main.py","path":"modules/eks-cluster-control-plane/control_plane_scripts/upgrade_cluster/main.py","sha":"af8d29a692f2530b74b9581464aca7bd06c255cd"}]}]},{"name":"dependencies.tf","path":"modules/eks-cluster-control-plane/dependencies.tf","sha":"6389b5cb477cef74e9bae294c41bbdd05b8d8aa5"},{"name":"main.tf","path":"modules/eks-cluster-control-plane/main.tf","sha":"c7e85a3b55d4067a1db20d5d49ff405551294773"},{"name":"outputs.tf","path":"modules/eks-cluster-control-plane/outputs.tf","sha":"d0e7b893effa8a7f02ee6d961e391cfc27a876c3"},{"name":"templates","children":[{"name":"kubectl_config.tpl","path":"modules/eks-cluster-control-plane/templates/kubectl_config.tpl","sha":"083a5e914505363541190db3ee412d8d9e15b4ec"}]},{"name":"variables.tf","path":"modules/eks-cluster-control-plane/variables.tf","sha":"f16008adb9f5302443f0becb86018fc7a02716b3"}]},{"name":"eks-cluster-managed-workers","children":[{"name":"README.md","path":"modules/eks-cluster-managed-workers/README.md","sha":"a44255e58e4c5949e3216339358124593ae2bbae"},{"name":"main.tf","path":"modules/eks-cluster-managed-workers/main.tf","sha":"15c9d27f99b9bf1a3066b831abb0ccc118ff5ca0"},{"name":"outputs.tf","path":"modules/eks-cluster-managed-workers/outputs.tf","sha":"391b5aff36a080568d94aae450d00b78488fb2e4"},{"name":"variables.tf","path":"modules/eks-cluster-managed-workers/variables.tf","sha":"fbb0d0efade0cb20f388b3c0f9cfeebf4cd87ff3"}]},{"name":"eks-cluster-workers-cross-access","children":[{"name":"README.md","path":"modules/eks-cluster-workers-cross-access/README.md","sha":"6c4e50bda62acc6c06d836488ef54f7119f27aee"},{"name":"main.tf","path":"modules/eks-cluster-workers-cross-access/main.tf","sha":"30885a053867992d0c3ee3804ba6833ae463c116"},{"name":"outputs.tf","path":"modules/eks-cluster-workers-cross-access/outputs.tf","sha":"c6c7f7a89007c55be5470ffd639c05c3fb052ad7"},{"name":"variables.tf","path":"modules/eks-cluster-workers-cross-access/variables.tf","sha":"d64aab893b6e909416189e985f072dd8809dfa2f"}]},{"name":"eks-cluster-workers","children":[{"name":"README.md","path":"modules/eks-cluster-workers/README.md","sha":"fa6ba2fe581b09829935936aa6232c3d3f60b268"},{"name":"dependencies.tf","path":"modules/eks-cluster-workers/dependencies.tf","sha":"57ce2b550d2bd4a4a969fbb37cc058cd9825ea86"},{"name":"main.tf","path":"modules/eks-cluster-workers/main.tf","sha":"909567c8667810e40c52cc1b0aac209320ea997b"},{"name":"outputs.tf","path":"modules/eks-cluster-workers/outputs.tf","sha":"15a01dabd1c0a11011e2488c4df1f43468312454"},{"name":"variables.tf","path":"modules/eks-cluster-workers/variables.tf","sha":"d646d70fb828c1c6385f6ff3c5935c27011ae4d0"}]},{"name":"eks-iam-role-assume-role-policy-for-service-account","children":[{"name":"README.md","path":"modules/eks-iam-role-assume-role-policy-for-service-account/README.md","sha":"efbbbd70fea3661c662750768facb7950239ffa3"},{"name":"main.tf","path":"modules/eks-iam-role-assume-role-policy-for-service-account/main.tf","sha":"be2fefe5e1a29a2582d1dcdc0b700b74f198cfc9"},{"name":"outputs.tf","path":"modules/eks-iam-role-assume-role-policy-for-service-account/outputs.tf","sha":"c2910cec89910bb06a157311ac8c4bf72835dfe5"},{"name":"variables.tf","path":"modules/eks-iam-role-assume-role-policy-for-service-account/variables.tf","sha":"dc660ddf84158851145289f6036a0fc19fbf7ce4"}]},{"name":"eks-k8s-cluster-autoscaler-iam-policy","children":[{"name":"README.md","path":"modules/eks-k8s-cluster-autoscaler-iam-policy/README.md","sha":"a22e2264a296fe1bf00f2c8b2f72ae728d0277c3"},{"name":"main.tf","path":"modules/eks-k8s-cluster-autoscaler-iam-policy/main.tf","sha":"c743f0e3523119155e2f2a6434e6f634d659aaee"},{"name":"outputs.tf","path":"modules/eks-k8s-cluster-autoscaler-iam-policy/outputs.tf","sha":"8b6c4e1747b3fa6a88c6233ec87aa2f450dfd334"},{"name":"variables.tf","path":"modules/eks-k8s-cluster-autoscaler-iam-policy/variables.tf","sha":"be3db9023160b3754187f2f21ce77772b43ced53"}]},{"name":"eks-k8s-cluster-autoscaler","children":[{"name":"README.md","path":"modules/eks-k8s-cluster-autoscaler/README.md","sha":"a74848607c42fcef696f121c2506ace0b83ced87"},{"name":"main.tf","path":"modules/eks-k8s-cluster-autoscaler/main.tf","sha":"f39dcbe11cfff6a81e23f3517c53d67420eccc37"},{"name":"templates","children":[{"name":"node_affinity.yaml","path":"modules/eks-k8s-cluster-autoscaler/templates/node_affinity.yaml","sha":"c6eaf8e94fa7c893857cc009df954443239a8fe0"},{"name":"values.yaml","path":"modules/eks-k8s-cluster-autoscaler/templates/values.yaml","sha":"4fad2031b54ad610fcd65abb03020d7d2db924de"}]},{"name":"variables.tf","path":"modules/eks-k8s-cluster-autoscaler/variables.tf","sha":"039ab2f131f0f8b6dd7399e8dcf2094d1ed616de"}]},{"name":"eks-k8s-external-dns-iam-policy","children":[{"name":"README.md","path":"modules/eks-k8s-external-dns-iam-policy/README.md","sha":"a33d41f9824e6270ef4573d6b7e22b394224689c"},{"name":"main.tf","path":"modules/eks-k8s-external-dns-iam-policy/main.tf","sha":"b346bd0324c30907dd62ac89f93fe9cc7799fd4d"},{"name":"outputs.tf","path":"modules/eks-k8s-external-dns-iam-policy/outputs.tf","sha":"21604a63b741b94ea9ebffd20b18772131020fcf"},{"name":"variables.tf","path":"modules/eks-k8s-external-dns-iam-policy/variables.tf","sha":"250152e6bfeb02a16bed4151ffc7156636db1bd9"}]},{"name":"eks-k8s-external-dns","children":[{"name":"README.md","path":"modules/eks-k8s-external-dns/README.md","sha":"59199651539725e656c97f18fefee22e39e311a5"},{"name":"main.tf","path":"modules/eks-k8s-external-dns/main.tf","sha":"7696052822928880e4da50296c7dd2ccdf32e267"},{"name":"templates","children":[{"name":"node_affinity.yaml","path":"modules/eks-k8s-external-dns/templates/node_affinity.yaml","sha":"c6eaf8e94fa7c893857cc009df954443239a8fe0"},{"name":"values.yaml","path":"modules/eks-k8s-external-dns/templates/values.yaml","sha":"ed22e91abbdc486ba7b0e79f28f63853b3860969"}]},{"name":"variables.tf","path":"modules/eks-k8s-external-dns/variables.tf","sha":"5f385a2e0aeef50a2f99b9e94f8648ecb7561b7d"}]},{"name":"eks-k8s-role-mapping","children":[{"name":"README.md","path":"modules/eks-k8s-role-mapping/README.md","sha":"eda8f8d176a772c66fb9ba39e0db186cb51a3c9c","toggled":true},{"name":"main.tf","path":"modules/eks-k8s-role-mapping/main.tf","sha":"6fcd7d1fefe10d1ed9b22cf16a1c272c347d1cfa"},{"name":"outputs.tf","path":"modules/eks-k8s-role-mapping/outputs.tf","sha":"95d4d4ec652bb541b91a2844e00f68064b423e60"},{"name":"variables.tf","path":"modules/eks-k8s-role-mapping/variables.tf","sha":"87e3ec8e2456d90175fa4c5cf0110bae86998170"}],"toggled":true},{"name":"eks-scripts","children":[{"name":"README.md","path":"modules/eks-scripts/README.md","sha":"96baaf535647b9f4c364d6a19057bcccb42df2be"},{"name":"bin","children":[{"name":"map-ec2-tags-to-node-labels","path":"modules/eks-scripts/bin/map-ec2-tags-to-node-labels","sha":"8087c82d4d47f25439f118c2a51e59d22689ada7"},{"name":"map_ec2_tags_to_node_labels.py","path":"modules/eks-scripts/bin/map_ec2_tags_to_node_labels.py","sha":"f75ad19587e95b2bd8924125ea2a1a697154909f"}]},{"name":"dev_requirements.txt","path":"modules/eks-scripts/dev_requirements.txt","sha":"f56f9d1629a85734fe16ed70f00f36b830cd97c9"},{"name":"install.sh","path":"modules/eks-scripts/install.sh","sha":"7f192fca97b098482a8a398019d4d53f45dba478"}]},{"name":"eks-vpc-tags","children":[{"name":"README.md","path":"modules/eks-vpc-tags/README.md","sha":"b53e923baaa79718b55a272158ff9b710871a6ce"},{"name":"outputs.tf","path":"modules/eks-vpc-tags/outputs.tf","sha":"0ef2787cfd02ea8668c687302b1929618079a0b2"},{"name":"variables.tf","path":"modules/eks-vpc-tags/variables.tf","sha":"a6e332e9da4e473e1e42b1ca6c7b0ba139a77cfb"},{"name":"versions.tf","path":"modules/eks-vpc-tags/versions.tf","sha":"e5d003c3e7a7296ca0f610fc77f94f2139fc59d2"}]}],"toggled":true},{"name":"rfc","children":[{"name":"shipping-logs-to-cloudwatch.md","path":"rfc/shipping-logs-to-cloudwatch.md","sha":"3ac6a0fd509477c36e1b4079e82ed3def7fe03d8"}]},{"name":"setup.cfg","path":"setup.cfg","sha":"981bc2bfd0b35029438d56c6d862a7f1519b8fe6"},{"name":"test","children":[{"name":"README.md","path":"test/README.md","sha":"9bf8180d731bdc892279fcdbcbb03d245f31f83a"},{"name":"eks_cluster_integration_test.go","path":"test/eks_cluster_integration_test.go","sha":"706f2eda374a9a831febfe04d72f2df01cf87533"},{"name":"eks_cluster_managed_workers_test.go","path":"test/eks_cluster_managed_workers_test.go","sha":"1eacfe2ec7d3a375c975ede65b028459bd9a0695"},{"name":"eks_cluster_test_helpers.go","path":"test/eks_cluster_test_helpers.go","sha":"ea30d40f827611931ca5bfa719e1d2de8f46d59a"},{"name":"eks_cluster_upgrade_test.go","path":"test/eks_cluster_upgrade_test.go","sha":"d28c893e72373d7c19115820f24f7cf632fd6c8c"},{"name":"eks_cluster_with_iam_role_test.go","path":"test/eks_cluster_with_iam_role_test.go","sha":"ca0b2f65ebffee9c417c59c49884b4034c6ca895"},{"name":"eks_cluster_with_supporting_services_test.go","path":"test/eks_cluster_with_supporting_services_test.go","sha":"0c99e8e8f747904133536fb3ca940f905e0e697e"},{"name":"eks_cluster_workers_optional_test.go","path":"test/eks_cluster_workers_optional_test.go","sha":"bc42df3ce9cf3ceb2aa9ae1484b4a25a389e7c8b"},{"name":"eks_envelope_encryption_test.go","path":"test/eks_envelope_encryption_test.go","sha":"3d8b92c4d3d4244c6431ccae95f0faeb0328bdce"},{"name":"eks_fargate_cluster_disable_public_endpoint_test.go","path":"test/eks_fargate_cluster_disable_public_endpoint_test.go","sha":"25ba0984ef5979ca146d16b63654559939d822db"},{"name":"eks_fargate_cluster_irsa_test.go","path":"test/eks_fargate_cluster_irsa_test.go","sha":"a066ec0cf9a8b7b949054de53f063d3ebe1c80e7"},{"name":"eks_fargate_cluster_public_access_cidr_test.go","path":"test/eks_fargate_cluster_public_access_cidr_test.go","sha":"2a82ad5a0bbb9311bb9c91a2c0be3f3dbe1b4d5e"},{"name":"eks_fargate_cluster_test.go","path":"test/eks_fargate_cluster_test.go","sha":"a50d3691cbdec0ba41e2212015105254d7a516c7"},{"name":"eks_fargate_cluster_with_supporting_services_test.go","path":"test/eks_fargate_cluster_with_supporting_services_test.go","sha":"a236dc2c1647da144a3fa973492b18ad80d64103"},{"name":"eks_mixed_cluster_dns_test.go","path":"test/eks_mixed_cluster_dns_test.go","sha":"dae0c9dd16808d92d6ba08977513798340767459"},{"name":"errors.go","path":"test/errors.go","sha":"be062fe0205ff82db8183d0fde639aa1883013ad"},{"name":"go.mod","path":"test/go.mod","sha":"ad9f275481179887ebada26ac28186866b827563"},{"name":"go.sum","path":"test/go.sum","sha":"7844bf26994c49320e11604a6ebb2b32afeecc6b"},{"name":"kubefixtures","children":[{"name":"autoscaler-test-pods-deployment.yml","path":"test/kubefixtures/autoscaler-test-pods-deployment.yml","sha":"b2d94c4bfa729b639290ee21629c19ca6ea694ee"},{"name":"eks-irsa-test.yml","path":"test/kubefixtures/eks-irsa-test.yml","sha":"db5439cf6d38873dbae71daa4197d6947990a94a"},{"name":"eks-k8s-role-mapping-test-role.yml","path":"test/kubefixtures/eks-k8s-role-mapping-test-role.yml","sha":"ede7587308d2a4ecf55042b05800099c43f3af7d"},{"name":"kube-system-sa-admin-binding.yml","path":"test/kubefixtures/kube-system-sa-admin-binding.yml","sha":"282d406512102cbe54e952575f26e7e0fbb2aa9a"},{"name":"nginx-deployment.yml","path":"test/kubefixtures/nginx-deployment.yml","sha":"a58866e59c113635af24982cfb0b530f0c416af0"},{"name":"robust-nginx-deployment.yml","path":"test/kubefixtures/robust-nginx-deployment.yml","sha":"87ead0f9733e422099bc430ed281e2054e698f10"}]},{"name":"script_tests","children":[{"name":"executor.sh","path":"test/script_tests/executor.sh","sha":"458c534996fbc045081d1cfae521c090f6787a7f"},{"name":"requirements.txt","path":"test/script_tests/requirements.txt","sha":"e855b2d366822bbc91b9d29140df9f060ceb6864"},{"name":"test_map_ec2_tags_to_node_labels.py","path":"test/script_tests/test_map_ec2_tags_to_node_labels.py","sha":"1bb3a5eae3727c0e6caf29c2cf4b7d596bb9a161"},{"name":"tox.ini","path":"test/script_tests/tox.ini","sha":"a7b8c79ca45e700e9cb7b8b493b37c68bc4408c2"}]},{"name":"terratest_options.go","path":"test/terratest_options.go","sha":"d0d60af0dcf531173547991d1f0c42a0c804474c"},{"name":"test_debug_helpers.go","path":"test/test_debug_helpers.go","sha":"c71a7a9d5b68f0f59d2518496d9f5893206b5e22"},{"name":"test_helpers.go","path":"test/test_helpers.go","sha":"698b84ae37f709f5e217b5f37d7b7d93320a7f15"}]}]},"detailsContent":"<h1 class=\"preview__body--title\" id=\"eks-k-8-s-role-mapping-module\">EKS K8S Role Mapping Module</h1><div class=\"preview__body--border\"></div><p>This Module can be used to manage the mapping of AWS IAM roles and users to Kubernetes RBAC groups for finer grained\naccess control of your EKS Cluster.</p>\n<p>This Module only manages the mapping between IAM roles and Kubernetes RBAC groups. This Module does not create, modify,\nor configure either roles. We recommend managing them in a separate Terraform template in the context of your needs,\nthat are then provided as inputs to this module.</p>\n<h2 class=\"preview__body--subtitle\" id=\"how-do-you-use-this-module\">How do you use this module?</h2>\n<ul>\n<li>See the <a href=\"/repos/v0.20.2/terraform-aws-eks/README.adoc\" class=\"preview__body--description--blue\">root README</a> for instructions on using Terraform modules.</li>\n<li>This module uses <a href=\"https://www.terraform.io/docs/providers/kubernetes/index.html\" class=\"preview__body--description--blue\" target=\"_blank\">the <code>kubernetes</code> provider</a>.</li>\n<li>See the <a href=\"/repos/v0.20.2/terraform-aws-eks/examples\" class=\"preview__body--description--blue\">examples</a> folder for example usage.</li>\n<li>See <a href=\"/repos/v0.20.2/terraform-aws-eks/modules/eks-k8s-role-mapping/variables.tf\" class=\"preview__body--description--blue\">variables.tf</a> for all the variables you can set on this module.</li>\n<li>See <a href=\"/repos/v0.20.2/terraform-aws-eks/modules/eks-k8s-role-mapping/outputs.tf\" class=\"preview__body--description--blue\">outputs.tf</a> for all the variables that are outputed by this module.</li>\n</ul>\n<h2 class=\"preview__body--subtitle\" id=\"what-is-kubernetes-role-based-access-control-rbac\">What is Kubernetes Role Based Access Control (RBAC)?</h2>\n<p><a href=\"https://kubernetes.io/docs/reference/access-authn-authz/rbac/\" class=\"preview__body--description--blue\" target=\"_blank\">Role Based Access Control (RBAC)</a> is a method to regulate\naccess to resources based on the role that individual users assume in an organization. Kubernetes allows you to define\nroles in the system that individual users inherit, and explicitly grant permissions to resources within the system to\nthose roles. The Control Plane will then honor those permissions when accessing the resources on Kubernetes on behalf of\nclients such as <code>kubectl</code>. When combined with namespaces, you can implement sophisticated control schemes that limit the\naccess of resources across the roles in your organization.</p>\n<p>The RBAC system is managed using <code>ClusterRole</code> and <code>ClusterRoleBinding</code> resources (or <code>Role</code> and <code>RoleBinding</code> resources\nif restricting to a single namespace). The <code>ClusterRole</code> (or <code>Role</code>) object defines a role in the Kubernetes system that\nhas explicit permissions on what it can and cannot do. These roles are then bound to users and groups using the\n<code>ClusterRoleBinding</code> (or <code>RoleBinding</code>) resource. An important thing to note here is that you do not explicitly create\nusers and groups using RBAC, and instead rely on the authentication system to implicitly create these entities.</p>\n<p>You can refer to <a href=\"#examples\" class=\"preview__body--description--blue\">the example scenarios</a> below for an example of this in action.</p>\n<p>Refer to <a href=\"https://kubernetes.io/docs/reference/access-authn-authz/rbac/\" class=\"preview__body--description--blue\" target=\"_blank\">the official documentation</a> for more\ninformation.</p>\n<h2 class=\"preview__body--subtitle\" id=\"what-is-an-aws-iam-role\">What is an AWS IAM role?</h2>\n<p><a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html\" class=\"preview__body--description--blue\" target=\"_blank\">AWS IAM role</a> is AWS's implementation of RBAC. Users\nand clients authenticate to AWS to assume an IAM role, that has a set of permissions that grant or deny access to\nvarious resources within AWS. Unlike users, IAM roles do not have long standing credentials associated with them.\nInstead, a user uses the AWS API to assume a role, which will issue temporary credentials that can be used to access the\nAWS resources as the assumed role. Like the roles in the Kubernetes RBAC implementation, you can configure the roles to have\nas much or as little permissions as necessary when accessing resources in the AWS system.</p>\n<p>This Module provides code for you to manage the mapping between AWS IAM roles and Kubernetes RBAC roles so that you can\nmaintain a consistent set of mappings between the two systems. This works hand in hand with the <a href=\"/repos/v0.20.2/terraform-aws-eks/core-concepts.md#how-do-i-authenticate-kubectl-to-the-eks-cluster\" class=\"preview__body--description--blue\">EKS authentication\nsystem</a>, providing the information to Kubernetes to resolve the user to the right RBAC group based on the provided IAM role credentials.</p>\n<h2 class=\"preview__body--subtitle\" id=\"examples\">Examples</h2>\n<h3 class=\"preview__body--subtitle\" id=\"restricting-specific-actions\">Restricting specific actions</h3>\n<p>Suppose that you are setting up your EKS cluster for your organization that has an ops team and a dev team. Suppose\nfurther that your organization would like to restrict access to your dev team so that they can only list and update\nexisting Pods, but can not create new ones, while the ops team is able to manage all resources in your Kubernetes\ncluster.</p>\n<p>To support this, we need to first define the roles in Kubernetes that map to the explicit permissions granted to each\nteam. For the ops team in Kubernetes, since we want to grant them admin level privileges on the cluster, we can use the\ndefault <code>system:admin</code> group that will already obtain those permissions. For the <code>dev</code> group however, there is no\ndefault group and role that fits our needs, so we need to define a new <code>ClusterRole</code> and bind it to the <code>dev</code> group. To do\nthis, we will first define the <code>ClusterRole</code> resource using the RBAC API:</p>\n<pre><span class=\"hljs-comment\"># dev-role.yml</span>\nkind: ClusterRole\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: dev\nrules:\n- apiGroups: [<span class=\"hljs-string\">\"\"</span>]\n resources: [<span class=\"hljs-string\">\"pods\"</span>]\n verbs: [<span class=\"hljs-string\">\"get\"</span>, <span class=\"hljs-string\">\"list\"</span>, <span class=\"hljs-string\">\"update\"</span>]\n</pre>\n<p>This creates a new role <code>dev</code> that allows the role to get, list, and update Pods in any namespace in the cluster. We can\napply this on the cluster using <code>kubectl</code>:</p>\n<pre>kubectl <span class=\"hljs-built_in\">apply</span> -f dev-role.yml\n</pre>\n<p>We then need to bind this to the <code>dev</code> group using a <code>ClusterRoleMapping</code> resource:</p>\n<pre><span class=\"hljs-comment\"># dev-role-binding.yml</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io/v1</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">ClusterRoleBinding</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">bind-dev</span>\n<span class=\"hljs-attr\">roleRef:</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">ClusterRole</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">dev</span>\n<span class=\"hljs-attr\">subjects:</span>\n<span class=\"hljs-bullet\">-</span> <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Group</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">dev</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n</pre>\n<p>This config binds the <code>ClusterRole</code> named <code>dev</code> to the <code>Group</code> named <code>dev</code>. Like the <code>ClusterRole</code> config, we can apply\nthis on the cluster using <code>kubectl</code>:</p>\n<pre><span class=\"hljs-symbol\">kubectl</span> apply -f dev-role-<span class=\"hljs-keyword\">binding.yml\n</span></pre>\n<p>Now that we have the two roles and bindings in the system, we need some way for users in the ops and dev teams to inherit\nthe roles. This is done implicitly by mapping their authentication credentials to their respective groups. In EKS,\nauthentication is handled by IAM, which means that we need to tell Kubernetes to map their IAM credentials to their\nrespective groups. We will use this Module to do exactly that.</p>\n<p>This Module takes as input a mapping between IAM roles and RBAC groups as part of the <code>iam_role_to_rbac_group_mapping</code>\ninput variable. In this example, we will assume that members of the ops team access the cluster by assuming the <code>ops</code>\nIAM role and members of the dev team access the cluster by assuming the <code>dev</code> IAM role, so we will map these to their\nrespective groups in Kubernetes:</p>\n<pre><span class=\"hljs-keyword\">module</span> <span class=\"hljs-string\">\"eks_k8s_role_mapping\"</span> {\n eks_worker_iam_role_arn = <span class=\"hljs-string\">\"arn.aws.iam::5555555555:role/eks-worker\"</span>\n\n iam_role_to_rbac_group_mappings = <span class=\"hljs-string\">\"${\n map(\n \"</span><span class=\"hljs-symbol\">arn:</span><span class=\"hljs-symbol\">aws:</span>iam::<span class=\"hljs-number\">555555555555</span><span class=\"hljs-symbol\">:role/dev<span class=\"hljs-string\">\", list(\"</span>dev<span class=\"hljs-string\">\"),\n \"</span>arn</span><span class=\"hljs-symbol\">:aws</span><span class=\"hljs-symbol\">:iam</span>::<span class=\"hljs-number\">555555555555</span><span class=\"hljs-symbol\">:role/ops<span class=\"hljs-string\">\", list(\"</span>system</span><span class=\"hljs-symbol\">:admin<span class=\"hljs-string\">\"),\n )\n }\"</span></span>\n}\n</pre>\n<p>When you <code>terraform apply</code> the above code, the Module will configure Kubernetes to resolve the provided AWS IAM roles to\nthe specified RBAC groups when fulfilling client requests. In this case, any <code>kubectl</code> authentications using the <code>dev</code>\nIAM role will resolve to the <code>dev</code> Kubernetes RBAC group, while any authentications using the <code>ops</code> IAM role will resolve\nto the <code>system:admin</code> Kubernetes RBAC group. The <code>dev</code> team will then implicitly inherit the <code>dev</code> <code>ClusterRole</code> based\non the <code>ClusterRoleBinding</code> that binds that role to the <code>dev</code> group.</p>\n<p><strong>Important</strong>: Note that we did not need to define the <code>dev</code> group explicitly in Kubernetes. This is automatically\nhandled by the authentication system. In Kubernetes, the group is implicitly defined as part of defining a user entity\nthat can map to it. As such, it is important to take care to avoid typos here to ensure that the string you use for the\ngroup here matches any groups referenced in the role bindings.</p>\n<h3 class=\"preview__body--subtitle\" id=\"restricting-by-namespace\">Restricting by namespace</h3>\n<p>In this example, suppose that you are setting up a dev EKS cluster for your dev team that is organized into multiple\nsubteams working on different products. In this scenario, you want to give members of the dev team full access to deploy\nand manage their applications, including deleting resources. However, you may want to implement controls so that teams\ncan only manage their own resources, and not others' resources.</p>\n<p>To support this, you would use <a href=\"https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/\" class=\"preview__body--description--blue\" target=\"_blank\">Kubernetes\nnamespaces</a> to partition your Kubernetes\ncluster. Namespaces allow you to divide your resources into logical groups on the cluster. By utilizing namespaces, you\ncan grant teams full access to resources launched in their own namespace, but restrict access to resources in other\nnamespaces.</p>\n<p>To implement this on your EKS cluster, you would first need to create namespaces for each team. For this example, we\nwill assume there are two dev teams in the organization: <code>api</code> and <code>backend</code>. So we will create a namespace for each\nteam:</p>\n<pre><span class=\"hljs-comment\"># namespaces.yml</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Namespace</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">v1</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">apiteam</span>\n <span class=\"hljs-attr\">labels:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">apiteam</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Namespace</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">v1</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">backendteam</span>\n <span class=\"hljs-attr\">labels:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">backendteam</span>\n</pre>\n<p>This will create two namespaces: one named <code>apiteam</code> and one named <code>backendteam</code>. We can apply this on the cluster using\n<code>kubectl</code>:</p>\n<pre>kubectl <span class=\"hljs-built_in\">apply</span> -f namespaces.yml\n</pre>\n<p>Next, we need to create RBAC roles in Kubernetes that grant access to each of the namespaces, but not others. To do this\nwe will rely on the <code>Role</code> resource, instead of the <code>ClusterRole</code> resource because we want to scope the permissions to a\nparticular namespace:</p>\n<pre><span class=\"hljs-comment\"># roles.yml</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Role</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io/v1beta1</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">apiteam-full-access</span>\n <span class=\"hljs-attr\">namespace:</span> <span class=\"hljs-string\">apiteam</span>\n<span class=\"hljs-attr\">rules:</span>\n<span class=\"hljs-bullet\">-</span> <span class=\"hljs-attr\">apiGroups:</span> <span class=\"hljs-string\">[\"\",</span> <span class=\"hljs-string\">\"extensions\"</span><span class=\"hljs-string\">,</span> <span class=\"hljs-string\">\"apps\"</span><span class=\"hljs-string\">]</span>\n <span class=\"hljs-attr\">resources:</span> <span class=\"hljs-string\">[\"*\"]</span>\n <span class=\"hljs-attr\">verbs:</span> <span class=\"hljs-string\">[\"*\"]</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Role</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io/v1beta1</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">backendteam-full-access</span>\n <span class=\"hljs-attr\">namespace:</span> <span class=\"hljs-string\">backendteam</span>\n<span class=\"hljs-attr\">rules:</span>\n<span class=\"hljs-bullet\">-</span> <span class=\"hljs-attr\">apiGroups:</span> <span class=\"hljs-string\">[\"\",</span> <span class=\"hljs-string\">\"extensions\"</span><span class=\"hljs-string\">,</span> <span class=\"hljs-string\">\"apps\"</span><span class=\"hljs-string\">]</span>\n <span class=\"hljs-attr\">resources:</span> <span class=\"hljs-string\">[\"*\"]</span>\n <span class=\"hljs-attr\">verbs:</span> <span class=\"hljs-string\">[\"*\"]</span>\n</pre>\n<p>This will create two roles in the Kubernetes cluster: <code>apiteam-full-access</code> and <code>backendteam-full-access</code>, each giving\nfull access to all resources in the respective namespaces. Like the YAML file for the namespaces, you can apply this on\nthe cluster using <code>kubectl</code>:</p>\n<pre>kubectl <span class=\"hljs-built_in\">apply</span> -f roles.yml\n</pre>\n<p>To allow authenticating entities to be able to inherit these roles, we need to map these to a group. We can do that by\ndefining <code>RoleBinding</code> resources:</p>\n<pre><span class=\"hljs-comment\"># role-bindings.yml</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io/v1</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">RoleBinding</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">bind-apiteam</span>\n <span class=\"hljs-attr\">namespace:</span> <span class=\"hljs-string\">apiteam</span>\n<span class=\"hljs-attr\">roleRef:</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Role</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">apiteam-full-access</span>\n<span class=\"hljs-attr\">subjects:</span>\n<span class=\"hljs-bullet\">-</span> <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Group</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">apiteam</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n<span class=\"hljs-meta\">---</span>\n<span class=\"hljs-attr\">apiVersion:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io/v1</span>\n<span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">RoleBinding</span>\n<span class=\"hljs-attr\">metadata:</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">bind-backendteam</span>\n <span class=\"hljs-attr\">namespace:</span> <span class=\"hljs-string\">backendteam</span>\n<span class=\"hljs-attr\">roleRef:</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Role</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">backendteam-full-access</span>\n<span class=\"hljs-attr\">subjects:</span>\n<span class=\"hljs-bullet\">-</span> <span class=\"hljs-attr\">kind:</span> <span class=\"hljs-string\">Group</span>\n <span class=\"hljs-attr\">name:</span> <span class=\"hljs-string\">backendteam</span>\n <span class=\"hljs-attr\">apiGroup:</span> <span class=\"hljs-string\">rbac.authorization.k8s.io</span>\n</pre>\n<p>These two resources bind the <code>apiteam</code> to the <code>apiteam-full-access</code> role and the <code>backendteam</code> to the\n<code>backendteam-full-access</code> role so that any client that maps to those groups will inherit the right permissions. We can\napply this to the cluster using <code>kubectl</code>:</p>\n<pre><span class=\"hljs-symbol\">kubectl</span> apply -f role-<span class=\"hljs-keyword\">bindings.yml\n</span></pre>\n<p>Now that we have the namespaces, the roles, and the bindings in the system, we need to create the AWS IAM roles that map\nto each team and tell Kubernetes to map the AWS IAM role to the proper RBAC role when authenticating the client. We will\nassume that the IAM roles already exist (named <code>ApiDeveloper</code> and <code>BackendDeveloper</code>). To map the IAM roles to the RBAC\ngroups, we will use this Module. This Module takes as input a mapping between IAM roles and RBAC roles as part of the\n<code>iam_role_to_rbac_group_mapping</code> input variable:</p>\n<pre><span class=\"hljs-keyword\">module</span> <span class=\"hljs-string\">\"eks_k8s_role_mapping\"</span> {\n eks_worker_iam_role_arn = <span class=\"hljs-string\">\"arn.aws.iam::5555555555:role/eks-worker\"</span>\n\n iam_role_to_rbac_group_mappings = <span class=\"hljs-string\">\"${\n map(\n \"</span><span class=\"hljs-symbol\">arn:</span><span class=\"hljs-symbol\">aws:</span>iam::<span class=\"hljs-number\">555555555555</span><span class=\"hljs-symbol\">:role/ApiDeveloper<span class=\"hljs-string\">\", list(\"</span>apiteam<span class=\"hljs-string\">\"),\n \"</span>arn</span><span class=\"hljs-symbol\">:aws</span><span class=\"hljs-symbol\">:iam</span>::<span class=\"hljs-number\">555555555555</span><span class=\"hljs-symbol\">:role/BackendDeveloper<span class=\"hljs-string\">\", list(\"</span>backendteam<span class=\"hljs-string\">\"),\n )\n }\"</span></span>\n}\n</pre>\n<p>When you <code>terraform apply</code> the above code, the Module will configure Kubernetes to resolve the provided AWS IAM roles to\nthe specified RBAC groups when fulfilling client requests. In this case, any <code>kubectl</code> authentications using the\n<code>ApiDeveloper</code> IAM role will resolve to the <code>apiteam</code> Kubernetes RBAC group, while any authentications using the\n<code>BackendDeveloper</code> IAM role will resolve to the <code>backendteam</code> Kubernetes RBAC group. In this way, the\ndevelopers who authenticate as <code>ApiDeveloper</code> will only be able to access the <code>apiteam</code> namespace in the Kubernetes\ncluster, while the developers who authenticate as <code>BackendDeveloper</code> will only be able to access the <code>backendteam</code>\nnamespace.</p>\n<p><strong>Important</strong>: Note that we did not need to define the <code>apiteam</code> and <code>backendteam</code> group explicitly in Kubernetes. This\nis automatically handled by the authentication system. In Kubernetes, the group is implicitly defined as part of\ndefining a user entity that can map to it. As such, it is important to take care to avoid typos here to ensure that the\nstring you use for the group here matches any groups referenced in the role bindings.</p>\n<h2 class=\"preview__body--subtitle\" id=\"why-not-use-a-helm-chart\">Why not use a Helm Chart?</h2>\n<p>This Module cannot be implemented as a helm chart due to the functionality of the ConfigMap being generated here. In\nEKS, the worker nodes also use an IAM role to authenticate against the EKS Control Plane. As such, the worker nodes rely\non the mapping from the <code>aws-auth</code> ConfigMap generated by this module to be able to successfully register to the EKS\ncluster as a worker node.</p>\n<p>To use Helm, the Kubernetes cluster must be running the Tiller (Helm Server) Pods on the cluster. However, to run the\nTiller Pods, the cluster must have worker nodes online and available. As such, we have a chicken and egg situation,\nwhere to use Helm we need to have worker nodes, which need the <code>aws-auth</code> ConfigMap, which needs Helm.</p>\n<p>To avoid this cyclic dependency, we implement this module using the <code>kubernetes</code> provider which will use <code>kubectl</code> under\nthe hood. The cluster requirement for a working <code>kubectl</code> is the EKS control plane, which will be available without the\nConfigMap and as such does not have the cyclic dependency problem of Helm.</p>\n","repoName":"terraform-aws-eks","repoRef":"v0.20.3","serviceDescriptor":{"serviceName":"EC2 Kubernetes Service (EKS) Cluster","serviceRepoName":"terraform-aws-eks","serviceRepoOrg":"gruntwork-io","cloudProviders":["aws"],"description":"Deploy a Kubernetes cluster on top of Amazon EC2 Kubernetes Service (EKS).","imageUrl":"eks.png","licenseType":"subscriber","technologies":["Terraform","Python","Bash"],"compliance":[],"tags":[""]},"serviceCategoryName":"Docker orchestration","fileName":"README.md","filePath":"/modules/eks-k8s-role-mapping/README.md","title":"Repo Browser: EC2 Kubernetes Service (EKS) Cluster","description":"Browse the repos in the Gruntwork Infrastructure as Code Library."}
.circleci
main.tf
