The Four Cs of Cloud Native Security

Security and the 4C Model / Guide 26 of 46 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 18 min

The defaults probed here are kubeadm's, and they are deliberate rather than accidental - NodeRestriction alone, and no encryption provider unless you configure one.

• etcd3.6.8
• Hardeningkubeadm defaults, none applied

This guide includes

Use this when you need a structure for reasoning about Kubernetes security rather than a list of settings to apply. This matters because Cloud, Cluster, Container and Code fail in different ways, and a control at one layer does nothing for the other three.

• listing which control-plane ports are actually listening - 6443, 2379, 10250 - and what can reach them
• reading anonymous-auth, authorization-mode and the admission plugins the API server was started with
• asking what system:anonymous is permitted to do
• running a container with no securityContext and finding it is root by default
• reading a Secret back and seeing that it is base64 encoding, not encryption

Before you start

• Root on a control-plane node, to read the static Pod manifests and the listening sockets.
• The Pod Security admission guide, which covers the namespace-label half of the cluster layer.

1. 1

   Cloud: what the network can reach

2. 2

   Cluster: who the API server trusts

3. 3

   Container: root by default

4. 4

   Code: a Secret is not encrypted

Official sources

• The 4C model
• Encrypting Secret data at rest
• Pod security context
• Controlling access to the kubelet