How to pass CKS — Kubernetes Security Specialist exam. Part 6

CKS requires CKA (Certified Kubernetes Administrator) passed first. It is a mandatory pre-request. I shared my tips in a different post on how to pass CKA and CKAD. If you received CKA, know how to use kubectl and Kubernetes documentation in an efficient way, you can start study for CKS. CKS is harder than the other two K8s exams. Good preparation requires deep study of native and external Kubernetes security tools, best security practices, and also requires a good knowledge of Kubernetes architecture, especially about API server, etcd, and kubelet. The exam covers the following areas: gVisor, AppArmor, RBAC, Network Policies, Auditing, Falco,Trivy, Admission Controllers, CIS Benchmark, Pod Security Policies, writing secure Dockerfiles, Secrets, Privileged Pods.

1. Episode — Network Policies
2. Episode — gVisor
3. Episode — Trivy
4. Episode — AppArmor
5. Episode — PodSecurityPolicies
6. RBAC
7. Dockerfile & SecurityContext

RBAC (Role-based access control)

RBAC is a method of regulating access to a computer or network resources based on the roles of individual users. RBAC authorization uses the API rbac.authorization.k8s.io to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

To enable RBAC, start the API server with the --authorization-mode flag set to a comma-separated list that includes RBAC; for example:

kube-apiserver --authorization-mode=Example,RBAC --other-options

In general, there are three steps that can be performed in this scenario. We need to create a Service Account , create ClusterRole or Role and create ClusterRoleBinding or RoleBinding . ClusterRole or Role contains rules that represent a set of permissions. ClusterRole is global, is a non-namespaced resource. Role always sets permissions within a particular namespace. ClusterRoleBinding or RoleBinding can be used to bind a ClusterRole or Role to Service Account or User.

Let’s start from a new namespace for this exercise and create ns rbac-test

alias k=kubectl
k create ns rbac-test
namespace/rbac-test created

create in namespace rbac-test Service Account (SA) called rbac-sa

k -n rbac-test create sa rbac-sa
serviceaccount/rbac-sa created

If I want to create Kubernetes resource I always use kubectl -h — it will display help that shows ready to use examples and hints, for ClusterRole creation I do

k create clusterrole -h
Examples:
  # Create a ClusterRole named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
  
  # Create a ClusterRole named "pod-reader" with ResourceName specified
  kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod
--resource-name=anotherpod
Usage:
  kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename]
[--dry-run=server|client|none] [options]

and I know what are the correct options for ClusterRole creation. Let's create now ClusterRole called rbac-cluster-role . rbac-cluster-rolewill allow to create andlistPods, Deployments, and Statefulsets.

k create clusterrole rbac-cluster-role --verb create,list --resource pods,deployments,sts
clusterrole.rbac.authorization.k8s.io/rbac-cluster-role created

we need to bind ClusterRole with rbac-sa Service Account

k create clusterrolebinding -h
Examples:
  # Create a ClusterRoleBinding for user1, user2, and group1 using the cluster-admin ClusterRole
  kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1
Usage:
  kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname]
[--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] [options]

correct command:

k create clusterrolebinding rbac-binding --clusterrole=rbac-cluster-role --serviceaccount=rbac-test:rbac-sa
clusterrolebinding.rbac.authorization.k8s.io/rbac-binding created

let’s test if RBAC works well via kubectl auth can-i

k auth can-i create sts --as=system:serviceaccount:rbac-test:rbac-sa -n rbac-test 
yes
k auth can-i list sts --as=system:serviceaccount:rbac-test:rbac-sa 
-n rbac-test 
yes
kubectl auth can-i delete sts --as=system:serviceaccount:rbac-test:rbac-sa -n rbac-test 
no

you can also be asked to change already existing ClusterRole or Role due to too open permissions, not align with Least Privilege Principle. For example, let’s restrict our ClusterRole rbac-cluster-role and remove create Pods, Deployments, and Statefulsets privilege

k edit clusterrole rbac-cluster-role -n rbac-test

and remove -create

# k edit clusterrole rbac-cluster-role -n rbac-test
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2021-04-12T18:35:24Z"
  name: rbac-cluster-role
  resourceVersion: "22140"
  uid: 77207f5f-a2da-4638-87b1-c47515825704
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - create.  # REMOVE
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  - statefulsets
  verbs:
  - create.   # REMOVE
  - list
~

time to test it again

k auth can-i create sts --as=system:serviceaccount:rbac-test:rbac-sa -n rbac-test 
no
k auth can-i create pod --as=system:serviceaccount:rbac-test:rbac-sa -n rbac-test 
no
k auth can-i list pod --as=system:serviceaccount:rbac-test:rbac-sa -n rbac-test 
yes