CKA Kubernetes ( K8S ) Security

 The preparation for the CKA (Certified Kubernetes Administrator) requires lots of practice and practice. Fortunately, we have lots of online playgrounds to keep practicing, there are lots of free courseware available and lots of paid as well are available. In addition to that, we get two attempts to clear the exam

• There is training conducted by the https://training.linuxfoundation.org/ itself who conducts the CKA exams. 
• But I felt this course from Udemy is good https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/, it has videos that explain each concept and have lots of practical sessions and mock exams.
• The https://killer.sh/ is another tool where you can practice and the questions asked in the killer.sh are complex and tests real skill.  If we subscribe to the CKA exam, we will get two free sessions to solve the problems in the killer.sh
• https://www.katacoda.com/courses/kubernetes this is very useful if you are a beginner in kubernetes. It starts with a very simple usecase/scenario and we can solve in our own pace and try any number of times
• https://killercoda.com/ is another useful online tool that we can use like a playground to solve scenario-based problems

kube-apiserver security

• It is the center of k8s and we need to secure it

• Who can access?

○ Authentication using password, token or 3rd party authentication

○ Service account for third party services

• What they can do?

○ Authorization using - RBAC (Role Based Access Control), ABAC (Attribute Based Access Control)

• Communication with other components like etcd-cluster, kube-controller, kube-scheduler etc are controlled by using the TLS certificate

• Communication between pod in the cluster can be restricted using NetworkPolicy

Authentication

• Different Users

○ Administrator

○ Developer

○ End-User

○ Third part apps

• Two types accounts we need to take care

○ User - Human

○ Service Account - other process or services

• User account is managed through the kube-apiserver and

○ different authentication method supported by kube-apiserver are

§ static password file

§ static token file

§ certificate

§ using third party like LDAP, Kerberos

○ While starting the kube-apiserver we need to pass the argument '--basic-auth-file=/var/user-credentials.csv'

TLS Authentication

• Uses symmetric and asymmetric keys for passing information between client and server

• Certificate is issued by Certificate Authority to confirm whether the server that sends the certificate is actually them

• PKI - Public Key Infrastructure

• Naming convention for keys

○ Public Key - *.crt, *.pem

○ Private Key - *.key, *-key.pem

TLS in Kubernetes

• 3 types of Certificates

○ Server Certificate

○ Client Certificate

○ Root Certificate (Signing Authority Cert)

• In K8S, we generate client and server key for components like

○ k8s-apiserver

○ etcd

○ kubelet

○ kube-proxy

○ controller-manager

○ scheduler

○ kubectl

○ ca-authority

• K8S mandates to have one Certificate Authority per cluster, we can have more than one CA but atleast one should be there

Generating Certificates in K8S

• There are many tools to create private key and certificate like

○ openssl

○ easyrsa

○ cfssl

• Commands

○ openssl genrsa -out ca.key 2048   => For creating private key

○ openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr   => For creating a CSR or Certificate Signing Request file

○ openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt => For creating the signed certificate, for CA we use the its own private key for signing the certificate

○ openssl x509 -in apiserver.crt -text -noout => for viewing the certificate details

Certificate API

• Its a k8s managed object which takes care of signing the CSR (Certificate Signing Requests)

• The controller manager is responsible for managing the csr requests and approving etc

kubeconfig

• It contains 3 informations

○ Clusters - dev, prod, test etc

○ Contexts - which user account uses for which cluster etc

○ Users - user account with we we have access to

• $HOME/.kube/config is a Config object in k8s and we need to define in a YAML file

API Groups

• There are multiple different APIs K8S provides

○ /version API

○ /log API

○ /healthz API

○ /api  -> core groups like namespaces, node, pods, configmaps, secret etc

○ /apis -> named groups are more organized based on apps, extensions, networking, storage, certificate, authentication etc

○ /metrics

• We can use http://master-node:6443 -k --key= --cert= --cacert=

• Or we can start the 'kubectl proxy' and we can access with http://127.0.0.1:8001 without any certificate, key etc

Authorization

• Different AuthorizationMode which we can set via the --authorization-mode attribue while starting the kube-apiserver. We can have multiple authorization mode defined and the check will happen in a chain

○ Node Authorizer - Node can access the kube-api server based on the certificate configuration

○ ABAC (Attribute Based Access Control) - A policy file needs to be created in a JSON format which tells which user or user-group has what access etc and then we need to restart the kube-api server

○ RBAC (Role Based Access Control) - Here we first define the role and then map user or user-group to the defined role. Will be easy to manage

○ Webhook - kube-apiserver checks with third party tool like open-policy-agent which manages the authorization level and will respond back

○ AlwaysAllow

○ AlwaysDeny

• We can configure in a way like a particular user has access to a certain namespace only

RBAC

• Role is a kubernetes object and we can define using a yaml definition

• RoleBinding is another object which links the user with Role

• Command to check whether the user can access or not

○ kubectl auth can-i create deployments

Cluster Role and RoleBinding

• Role and RoleBindings are a namespace resource and we cannot use Role and RoleBinding for allowing/restricting node access

• For a node resource, we need to use ClusterRole 

• Kubernetes resources can be in one of the below scope

○ Namespace scoped

○ Cluster scoped

• Example of Cluster scoped resources

○ nodes

○ PV (Persistence Volume)

○ clusterroles

○ clusterrolebinding

○ certificatesigningrequest

○ namespaces

○ ..

• The ClusterRole allows access to all the namespaces

Security Contexts

• We can specify what is the userId the container is running or the unix capability

• We can set these context at the POD level or at the container level. However the capability can be set only at container level

securityContext:

    runAsUser: 1000

    capabilities:

       add: ["MAC_ADMIN"]

Network Policy

• By default the network rule set by kubernetes is 'AllAllow' which means any pod can reach to any other pod without restriction

• NetworkPolicy is another object in kubernetes namespace

• We can link NetworkPolicy to one or more pods using the label selector

• There are many implementation for networking in k8s

○ flannel

○ Calico

○ Romana