Before using kubectl, please set the KUBECONFIG environment variable to point to the right kubeconfig file.
$ export KUBECONFIG=../02-Multi-node_cluster/vagrant/kubeconfig.yaml
Also, openssl must be installed on your PC.
From Kubernetes 1.6 onwards, RBAC policies are enabled by default.
One basic Kubernetes feature is that all its resources are modeled API objects, which allow CRUD (Create, Read, Update, Delete) operations. Examples of resources are:
- Pods
- PersistentVolumes
- ConfigMaps
- Deployments
- Nodes
- Secrets
- Namespaces
Examples of possible operations over these resources are:
- create
- get
- delete
- list
- update
- edit
- watch
- exec
At a higher level, resources are associated with API Groups (for example, Pods belong to the core API group whereas Deployments belong to the apps API group). For more information about all available resources, operations, and API groups, check the Official Kubernetes API Reference.
To manage RBAC in Kubernetes, apart from resources and operations, we need the following elements:
- Rules: A rule is a set of operations (verbs) that can be carried out on a group of resources which belong to different API Groups.
- Roles and ClusterRoles: Both consist of rules. The difference between a Role and a ClusterRole is the scope: in a Role, the rules are applicable to a single namespace, whereas a ClusterRole is cluster-wide, so the rules are applicable to more than one namespace. ClusterRoles can define rules for cluster-scoped resources (such as nodes) as well. Both Roles and ClusterRoles are mapped as API Resources inside our cluster.
- Subjects: These correspond to the entity that attempts an operation in the cluster. There are three types of subjects:
- User Accounts: These are global, and meant for humans or processes living outside the cluster. There is no associated resource API Object in the Kubernetes cluster.
- Service Accounts: This kind of account is namespaced and meant for intra-cluster processes running inside pods, which want to authenticate against the API.
- Groups: This is used for referring to multiple accounts. There are some groups created by default such as cluster-admin.
- RoleBindings and ClusterRoleBindings: Just as the names imply, these bind subjects to roles (i.e. the operations a given user can perform). As for Roles and ClusterRoles, the difference lies in the scope: a RoleBinding will make the rules effective inside a namespace, whereas a ClusterRoleBinding will make the rules effective in all namespaces.
In this example, we will create the following User Account:
Username: denis Group: sunnyvale
We will add the necessary RBAC policies so this user can fully manage deployments (i.e. use kubectl run command) only inside the office namespace. At the end, we will test the policies to make sure they work as expected.
Execute the kubectl create command to create the namespace (as the admin user):
$ kubectl create namespace office
namespace/office created
Create The User Credentials.
Create a private key for your user. In this example, we will name the file employee.key
$ openssl genrsa -out denis.key 2048
Generating RSA private key, 2048 bit long modulus
.............+++
...................................................................................................................................................+++
e is 65537 (0x10001)
Create a certificate sign request employee.csr using the private key you just created (denis.key in this example). Make sure you specify your username and group in the -subj section (CN is for the username and O for the group). As previously mentioned, we will use denis as the name and sunnyvale as the group:
$ openssl req -new -key denis.key -out denis.csr -subj "/CN=denis/O=sunnyvale"
In the current directory you will find the Kubernetes cluster certification authority's (CA) key and certificate, copied here by the Kubernetes installation procedure (normally they reside in /etc/kubernetes/pki/ on the master node).
Let's generate the final certificate employee.crt by approving the previously created certificate sign request.
$ openssl x509 -req -in denis.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out denis.crt -days 500
Signature ok
subject=/CN=denis/O=sunnyvale
Getting CA Private Key
Add a new context with the new credentials for your Kubernetes cluster.
$ kubectl config set-credentials denis --client-certificate=./denis.crt --client-key=./denis.key
User "denis" set.
$ kubectl config set-context denis-context --cluster=kubernetes --namespace=office --user=denis
Context "denis-context" created.
Now you should get an access denied error when using the kubectl CLI with this configuration file. This is expected as we have not defined any permitted operations for this user.
$ kubectl --context=denis-context get pods
Error from server (Forbidden): pods is forbidden: User "denis" cannot list resource "pods" in API group "" in the namespace "office"
Let's move ahead by creating the new deployment-manager role. To understand the role's capabilities just inspect the office_deployment-manager_role.yaml file.
$ kubectl apply -f office_deployment-manager_role.yaml
role.rbac.authorization.k8s.io/deployment-manager created
To bind the role to the denis user, yust apply the denis_office_deployment-manager_role_binding.yaml file as showed here after.
$ kubectl apply -f denis_office_deployment-manager_role_binding.yaml
rolebinding.rbac.authorization.k8s.io/deployment-manager-binding created
Now let's test the RBAC rule by deploying a new Pod with denis user:
$ kubectl --context=denis-context run --image bitnami/dokuwiki mydokuwiki
deployment.apps/mydokuwiki created
To test the same command it was failing before:
$ kubectl --context=denis-context get pods
NAME READY STATUS RESTARTS AGE
mydokuwiki-75d4b8ddb5-vttpb 1/1 Running 0 58s
Don't forget to clean-up before proceeding:
$ kubectl delete deployment mydokuwiki --namespace office
deployment.extensions "mydokuwiki" deleted
$ kubectl delete -f .
rolebinding.rbac.authorization.k8s.io "deployment-manager-binding" deleted
role.rbac.authorization.k8s.io "deployment-manager" deleted