Basic RBAC configuration for AWS EKS cluster

Imagine your AWS EKS (Kubernetes) cluster as a grand theater, with various actors playing distinct roles. RBAC ensures that each actor has the right script and costume, preventing unauthorized access or actions. This level of control is essential for keeping your cluster secure and efficient and is one of the challenges during cluster configuration.

Summary of the article

1. Two Kubernetes namespaces are created - 'development' and 'integration'.
2. 'Development' namespace is accessible to IAM users from the 'k8sDev' group.
3. 'Integration' namespace is accessible to IAM users from the 'k8sInteg' group.
4. Roles and RoleBindings are created in both namespaces for 'dev-user' and 'integ-user'.
5. The roles defined grant full access to various Kubernetes resources within their respective namespaces.
6. These roles are not ClusterRoles but are specific to the 'development' and 'integration' namespaces.
7. The configuration can be adapted or duplicated for other namespaces as needed.

IAM users from the 'k8sDev' group have full access to the 'development' namespace, and IAM users from the 'k8sInteg' group have full access to the 'integration' namespace using Role and RoleBinding configurations.

Preparation is a key - configure RBAC for kubernetes EKS

Before diving into RBAC configuration, let's gather our tools and set the stage. Ensure that you have 'kubectl' and 'eksctl' installed and configured. These will be your trusted companions on this journey. 

Creating RBAC Roles

In the world of RBAC, roles define the characters' actions. You can create roles using YAML manifests or, for the more adventurous, through the kubectl command-line tool.

cat <<< EOF | kubectl apply -f - -n development
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-role
rules:
  - apiGroups:
      - ""
      - "apps"
      - "batch"
      - "extensions"
    resources:
      -"configmaps"
      - "cronjobs"
      - "deployments"
      - "events"
      - "ingresses"
      - "jobs"
      - "pods"
      - "pods/attach"
      - "pods/exec"
      - "pods/log"
      - "pods/portforward"
      - "secrets"
      - "services"
    verbs:
      - "create"
      - "delete"
      - "describe"
      - "get"
      - "list"
      - "patch"
      - "update"
---  
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-role-binding
subjects:
  - name: dev-user
    kind: User
roleRef:
  name: dev-role
  kind: Role
  apiGroup: rbac.authorization.k8s.io
EOF

And the second manifest:

cat << EOF ❘ kubectl apply -f - -n integration
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: integ-role
rules:
  - apiGroups:
      - "apps"
      - "batch"
      - "extensions"
    resources:
      - "configmaps"
      - "cronjobs"
      - "deployments"
      - "events"
      - "ingresses"
      - "jobs"
      - "pods"
      - "pods/attach"
      - "pods/exec"
      - "pods/log"
      - "pods/portforward"
      - "secrets"
      - "services"
    verbs:
      - "create"
      - "delete"
      - "describe"
      - "get"
      - "list"
      - "patch"
      - "update"
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: RoleBinding
metadata:
  name: integ-role-binding
subjects:
  - name: integ-user
    kind: User
roleRef:
  name: integ-role
  kind: Role
  apiGroup: rbac.authorization.k8s.io
EOF

Binding Roles to Users and testing configuration

Roles alone won't make the magic happen. You need to bind these roles to users or groups to grant access. Kubernetes EKS supports RoleBindings and ClusterRoleBindings for this purpose. Roles are not ClusterRoles.

Configuring RBAC - a step-by-step guide

Step 1: Identify User Roles

The first step in implementing RBAC is to identify the different roles within your organization. Consider the responsibilities and access requirements of each role. Common roles may include administrators, managers, employees, and guests.

Step 2: Define Permissions

With roles identified, define the specific permissions associated with each role. What actions should users in each role be able to perform? Document these permissions comprehensively.

Step 3: Assign Users to Roles

Once you've established roles and their associated permissions, assign users to the appropriate roles. Ensure that users' roles align with their job functions and responsibilities.

Step 4: Implement RBAC in Your Systems

Now, it's time to integrate RBAC into your systems or applications. Most modern software platforms offer RBAC functionality, allowing you to map roles and permissions seamlessly.

Step 5: Regularly Review and Update

RBAC is not a set-it-and-forget-it solution. Regularly review and update roles and permissions as organizational needs evolve. Remove unnecessary privileges and add new ones as required.

Frequently Asked Questions (FAQ)

Q1: Is RBAC necessary for my Kubernetes EKS cluster?

Absolutely! RBAC is crucial for securing your cluster and managing access effectively. It's a must-have in today's cloud landscape and should be implemented at an earlier level of cluster configuration to avoid collecting tech debt.

Q2: Can I modify RBAC roles after initial configuration?

Yes, you can! Kubernetes EKS allows you to update RBAC roles and bindings dynamically. Just ensure you follow best practices and test thoroughly.

Q3: How can I troubleshoot RBAC issues if they arise during configuration?

Troubleshooting RBAC can be challenging. To start, you can use the 'kubectl' auth can-i command to check if a user or service account has specific permissions. Additionally, reviewing logs and auditing RBAC policies can help pinpoint and resolve any issues that may arise during configuration.