– 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.