kubernetes: Securing The Cluster






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

  • 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


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

  • Service account

  • RBAC

  • Cluster Role

  • Cluster Role Binding





Supported Authentication methods

  • TLS Certs

  • Bearer Token

  • X509 client certs

  • Static Token file

  • Static Password files

  • Service Account tokens


Authentication Example


  • 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 :-)








324 views0 comments
 

Subscribe Form

©2020 by Linux Advise