Container-specific security
I recently had an interesting discussion with Gianluca Brindisi from Spotify about the differences between Kubernetes security and container security. Typically, the discussion about container security focuses on general questions that aren’t focused on a specific orchestration framework like Kubernetes, such as the following:
What images do I run and do they have secure base images?
Is my image registry secure?
What operating system permissions do my containers run with?
Is my container network properly segmented?
What processes do my containers run, and what files do those processes access at runtime?
These are all important questions when zooming out and looking at container security in general. However, in the Kubernetes context, something is lost.
Kubernetes-specific security
Let’s illustrate the type of questions that you should ask to secure your Kubernetes cluster in addition to your containers. Some brief answers and tips are included for convenience.
Can someone bypass network segmentation by using the Kubernetes APIServer as a proxy and tunnel from one pod to another via kubectl port-forward?
It depends on what Role-Based Access Control (RBAC) permissions that pod’s service account has. (There isn’t much documentation around the pods/portforward role, but you can see it in the source code.)
If an attacker has breached one pod with restricted operating system permissions, can they escalate privileges by using the Kubernetes APIServer to launch a new pod with greater permissions?
Yes, if that pod’s service account has RBAC permissions to create a new pod and you haven’t set up additional restrictions like Pod Security Policies.
Can an attacker use raw-sockets to wreak havoc on the cluster’s container network?
Yes, by defa ..
Support the originator by clicking the read the rest link below.
