We cannot disagree with the fact that be it anything security is "THE" most important consideration. No one is going to bear the loss of data or any kind of security attack on the application cluster. This is the subject of this article.
Kubernetes Attack Entry Points
Access to the cluster nodes
Node here is a virtual machine and can also be a bare metal system.
Care should be taken that the servers are not accessible to everyone.
There should be no unnecessary open ports.
Access to the nodes should be limited and only to authorized person.
The basic OS hardening concepts should be applied here
Access to the etcd cluster – The key-value store
This is used by k8s cluster to record configuration and state information of cluster components.
Preferably etcd should be hosted on a separate server with in a private network.
A hacker can use that to gain read access to all the variables used in the system and get information about the resources.
Access to kube-api server
It’s a restful api server and is the only cluster component that should expose an API endpoint beyond the cluster private network. In most cases, it is exposing a port to public IP address.
This is the component which conveys request from each and every component in the cluster.
It should be made sure that this component is highly secure and for that TLS certificates should be used and this endpoint should be very much hardened.
Intercept/modify/inject control plane traffic
Proficient hackers can play with the inter process communication, can intercept the traffic, put their own code and steal secret digital assets.
Control plane components require TLS security when it is communicating with other parts.
Use of SSL certificates should be put to use and certs should be rotated regularly.
Access via Kubelet API
Kubelet sits on the worker node and communicates directly with API server. Hence communication should be secured using TLS
Container runtime itself need to be secured and is one of the most vulnerable entry points.
Also, as container running on the host share the same kernel as the host, so if there is any exploitable issue on the host, it can affect the container.
If any container is running in the privileged mode ( which is similar to a root user), then its really easy to reach the host.
Vulnerability can exists in the application software being deployed and that of course needs to be taken care as well.
Principle of Least Privileged
Be it any application or IT infra setup we should always give the right amount of access. No more , no less.
Talking in terms of Kubernetes there are different ways we can control the access
Segregation with namespace
Cluster Role Binding
Supported Authentication methods
X509 client certs
Static Token file
Static Password files
Service Account tokens
Create a service account
kubectl create serviceaccount jenkins
A secret token will be created for that service account.
Now we will run a pod using this service account using the below yaml file.
[linuxadvise@linuxadvise ~]$ cat pod2usewith-sa.demo.yaml apiVersion: v1 kind: Pod metadata: name: ks-demo-pod spec: serviceAccountName: jenkins containers: - name: shell image: alpine:3.7 command: - "sh" - "-c" - "sleep 10000"
[linuxadvise@linuxadvise ~]$ kubectl create -f pod2usewith-sa.demo.yaml pod/ks-demo-pod created [linuxadvise@linuxadvise ~]$ kubectl get pods NAME READY STATUS RESTARTS AGE ks-demo-pod 1/1 Running 0 7s kube-bench-928hn 0/1 Completed 0 73m nginx 1/1 Running 0 94m [linuxadvise@linuxadvise ~]$
The token generated for the service account is mounted on a volume.
We see that there is no concept of username and passwords in kubernetes. We authenticate through service account. As we can see as of now we have just defined the service account and not decided what it can do. This comes under authorization that is the subject of next article.
Happy Reading :-)