Best practices: network protection of Kubernetes control plane

[slashben]

Welcoming comments

General idea

In line with our goal of creating a "best practices" framework for Kubernetes CNF implementations, I would like to create another "best practice" document.

I want to address Kubernetes network security and isolation in high level with two major parts:

• Limit access to KubeAPI
• Secure communication between system components

Limit access to KubeAPI

The KubeAPI is the main gateway to a cluster and main target of any attacker. There are two components of protecting this API:

• Limiting network access: KubeAPI should never face the public network directly and firewall configuration should enable access to it only from specific VPC
• Configure KubAPI server to:
  • Only answer authenticated users (no “anonymous” access)
  • Enable RBAC
  • Disable “insecure access” configuration

Make sure Kubernetes system components are using secure communication

Attackers who are able to access the network in which the Kubernetes cluster is running can connect and manipulate system components or eavesdrop the communication between those components.
Kubernetes control plane components like API server, ETCD, controller-manager and
scheduler should be configured to use and enforce TLS with bilateral certificate based authentication.

[tliron]

Another aspect of the control plane is the container runtime (e.g. CRI-O). It requires network access to registries in order to download container images. That connectivity is not part of the KubeAPI.