Security In Kubernetes

I have learned following topics in this week. I want to share in public so that it will help to someone.

Certificate health check: Need to ensure following things

• 1. Correct CN, & ALT names, organizations are present for kube-api-server, nodes(kubelet)

• 2. Ensure the certificates are not expired.

• 3. Make sure the certificates are issued by the right CA.

• 4. Provide correct certificate path in service config file.

- Certificate API:

In the case of multiple users a manual authentication through controller manager will be difficult hence automate CSR approving and signing request. Certificate API will carry out this as following way.

- Kube Config:

It is K8S cluster configurations where we can configure the contexts. It is using to access the cluster.

Use Case:

If you are accessing the resources (pod) through kube-api-server using “curl”, need to authenticate through certificate for that we have to mention following things to authenticate.

curl https://my-k8s-lab:6443/api/v1/pods \

--key xyz.key

--cert xyz.crt

--cacert ca.crt

Instead of mentioning these details every time we can add these in one file in $home/.kube/config, that file is called as kube config file. This file contains 3 objects.

1. Cluster: Comes cluster related details like name, CA cert, server

2. Users: Username, client-certificate, client key

3. Contexts: context name, cluster name, user

It can be defined in the definition/yaml file.

- API Group:

It is responsible for cluster functionality means to access master node and the resources like pods.

There are following API groups available in K8S.

• /metrics

• /healthz

• /version

• /api

• /apis

• /logs

Out of these /api & /apis are important. /api is core and /apis is named. /apis is latest and upcoming changes will update in this group.

To access the resources (pod, replicaset, deployments etc) and verbs (list, get, create, delete, update, watch).

Kube proxy: It use to enable connectivity between the pod and services across diff nodes in the cluster.

Kubectl proxy – It is http proxy service created by kubectl utility to access the kube api server.

- Authorization:

• It authorize the user what he/she can do in cluster. It give set of permissions.

• It uses set of mechanism to authorize the users.

1. Node Authorization: Authorize through node system:group on the certificate.

2. ABAC: Manage through security config file in json. It is difficult to manage in case of multiple users

3. RBAC: This is the solution over ABAC. Authorization has happen through roles (developer, storage)

4. Webhook: It uses third party(open policy agent) tools to authorize.

- Cluster Roles:

• Roles that will be apply to whole cluster so that it can override to all namespace in cluster.

• Roles and rolebindings are applied on the namespace so apply on cluster objects a cluster roles are required.

• Example: If we want to apply the roles to nodes.

- Service Accounts:

• This account use by the machines, bots like application Prometheus, jenkins.

• It uses for application operations.

• It uses secret token object for secure authentication but this old way & non-expiry token.

• To fix this k8s introduced “TokenRequestAPI” in v1.22 update as part of KEP(kubernetes Enhancement Proposal 1205 – To bound service account tokens.

• One more enhancement v1.24 2799 happened and in that a token will not create automatically but can create manually with expiry.

• TokenRequestAPI is very secure and performance is fast.

- Image Security:

Images can make secure by following ways.

• User security – stop using root user in container.

• Docker secret – create a secret for private docker-registry using credentials and email for private server.

- Pre-requisite Security in Docker:

• User level – stop using root user in containers

• Linux Capabilities – It applies to container level

- Security Contexts:

• It is kubernetes security.

• It uses to specify the runAsUser, means the user can use to run the pod.

• It applies on the POD level.

- Network Policies:

• It helps to restrict the direct traffics to particular pod.

• It only talks/act about the directions of the traffics.

• Why it required?

  Kubernetes allows pods to communicate across the span of cluster. A virtual connectivity is there across the cluster but If want to restrict a web application directly communicate to DB server then we can do by creating the network policy.

- Developing Network Policies:

• How can create the network policy?

  By creating the definition/yaml file and specify ingress & Egress policy types.

• It uses podSelector labels to select pods and mention ports.

• Egress – Outing traffics from pod/resources to next resource.

  - to

  - ports

• Ingress – Incoming traffics to pod/resources.

  - from:

  - ports

- Kubectx & Kubens - command line utilities:

• Kubectx – command using to manage/play in case of multiple cluster contexts. We can switch diff contexts and return back with command line, not required to make changes in configuration file.

• Kubens: It users to deal with huge numbers of namespaces withing the clusters.