Overview
Kubernetes RBAC
RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows the configuration of flexible authorization policies that can be updated without cluster restarts.
In the RBAC API, a role contains rules that represent a set of permissions. Permissions are purely additive (there are no “deny” rules). A role can be defined within a namespace with a Role, or cluster-wide with a ClusterRole.
Kubernetes Account Types:
- User Account: when a human wants to access a cluster using API resources like kubectl, API calls, etc.)
- Service Account: when processes in containers inside pods access the cluster.
Now we see how users get access into the Kubernetes Cluster, the user passes through 2 stages.
- Authentication(AWS IAM)
- Authorization(RBAC)
Authentication
- Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins for creating a new user and authenticating them.
2. But in the Blog, we can authenticate the User using AWS IAM Service, we follow the below diagram.
With EKS you can take advantage of using powerful AWS IAM implementation. EKS authentication layers support both IAM Users and IAM Roles.
Amazon EKS uses Amazon EKS uses
aws-iam-authenticatorfor authentication to your Kubernetes cluster and Kubernetes RBAC for authorization.aws-iam-authenticatorIt is a tool to use AWS IAM credentials to authenticate to a Kubernetes cluster.How to create an IAM User
- Go to your AWS Console where you will find the IAM service listed under the “Security, Identity & Compliance” group. Inside the IAM dashboard click on the Users tab and click the “Add User” button.
2. Create a new user and allow the user programmatic access by clicking on the “Programmatic access” checkbox.
3. After the user is created, you will have access to the user’s Access Key ID and Secret Access Key. You will be required to use these keys in the next step.
Configure the AWS CLI
- Install AWS CLI on the EC2
2. Use the below comment to configure the User.
aws configure
Output:
So Authentication is completed, we going towards Authorization.
Authorization(RBAC)
For authorization of the user, we used an RBAC.
RBAC API objects.
- Role: A role contains rules that represent a set of permissions within a namespace.
- Rolebinding: A role binding grants the permissions defined in a role to a user or group of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted, Permissions can be granted within a namespace with a RoleBinding.
- Clusterrole: A role contains rules that represent a set of permissions across cluster or cluster-wide.
- ClusterRoleBinding: A Clusterrole binding grants the permissions defined in a role to a user or group of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted, Permissions can be granted cluster-wide with a ClusterRoleBinding.
Example
Manage access(RBAC) for specific namespace:
It should be noted that Roles and RoleBindings are namespaced, which means that the permissions can only be given for the Kubernetes resources that are in the same namespace as the Role and the RoleBinding. Also, it is without saying that a RoleBinding can only reference a Role that exists in its namespace.
Let’s say we have a User developer-user who wants to be able to list the pods in a namespace dev, Then the steps we need to follow
1.Create namespace
kubectl create namespace dev
2.Create an RBAC Role to namespace
In the example below, you can see a Role which allows listing pods in the namespace “dev”
# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer-user-role
namespace: dev
rules:
- apiGroups: ["*"]
resources: ["pods"]
verbs: ["list"]
API groups :
/api/v1 or /apis/extensions/v1beta1.
Resources: Resource is the K8s object that a subject wants to access. It could be pods, deployments, services, etc
Verbs: Verbs are the actions that a subject can do on resources. It could be the list, delete, create, watch, etc
Create the role:
kubectl create -f role.yaml
3.Create RoleBinding for Role
To give a user the permissions described in the previous Role it is necessary to create a RoleBinding. In the example below, the RoleBinding “developer-user-role-binding” binds the Role “developer-user-role” to the user “developer-user”
# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-user-role-binding
namespace: dev
subjects:
- kind: User
name: developer-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer-user-role
apiGroup: rbac.authorization.k8s.io
Subjects: The subject is the entity that needs access. It could be a user or group or a service account.
RoleRef: We bind the user with a role.
Create the RoleBinding:
kubectl create -f rolebinding.yaml
4. Adding the user to the aws-auth configmap
If you want to grant additional AWS users or roles the ability to interact with your EKS cluster, you must add the users/roles to the
aws-auth ConfigMap within Kubernetes in the kube-system namespace.
You can do this by either editing it using the
kubectl edit command:$ kubectl edit configmap aws-auth -n kube-system
Add the user under the
mapUsers as an item in the aws-auth ConfigMap:data:
mapUsers: |
- userarn: arn:aws:iam::12345678:user/developer-user
username: developer-user
groups:
- developer-user-role
mapUsers:
userarn: Add aws iam user arn.
username: Add the name of the user.
groups: put the role name
Output:
We give developer-user only pods access in dev namespace, so developer user can only view the pods in dev namespace and not able to access any other things like deployment, secret,replicaset, etc.
Manage access centralized using ClusterRole
ClusterRoles and ClusterRoleBindings which are useful in the following cases:
- Give permissions for non-namespaced resources like nodes
- Give permissions for resources in all the namespaces of a cluster
Example
Let’s say we have a User developer-user who wants to perform all the activities such as create, list, get, delete pods across the Cluster
So basically give developer-user admin access to pods resources across the cluster.
Then the steps we need to follow
- Create a Clusterrole
# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: adminpods
rules:
- apiGroups: ["*"]
resources: ["pods"]
verbs: ["*"]
API groups :
/api/v1 or /apis/extensions/v1beta1.
Resources: Resource is the K8s object that a subject wants to access. It could be pods, deployments, services, etc
Verbs: Verbs are the actions that a subject can do on resources. It could be the list, delete, create, watch, etc
Create the Clusterrole:
kubectl create -f clusterrole.yaml
2. Create a Clusterbinding.
In case you want to grant permissions for your IAM role in all namespaces, you can simply use ClusterRoleBinding as follows:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: pods_cluster_role_binding
subjects:
- kind: User
name: developer-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: adminpods
apiGroup: rbac.authorization.k8s.io
Create the Clusterrolebinding:
kubectl create -f clusterrolebinding.yaml
3. Adding the user to the aws-auth configmap
You can do this by either editing it using the
kubectl edit command:$ kubectl edit configmap aws-auth -n kube-system
Add the user under the
mapUsers as an item in the aws-auth ConfigMap:data:
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/developer-user
username: developer-user
groups:
- adminpods
Group: give the cluster role name.
Output:
In the below image u see developer-user able to access all pods in Cluster.
developer-user able to get pods in dev, qa, default namespaces also.
More things to do:
You can also perform different actions on different resources using adding below rules under the role or cluster role YAML file.
rules:
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods", "pods/log", "pods/exec"]
verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["list", "get", "create", "update", "delete"]
Conclusion
In this blog, we done Authentication of users using AWS IAM service, we bypass the traditional way of doing authentication in Kubernetes such as client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth.
Thank you, if you have any doubt reach out to me
Comments
Post a Comment