To perform any action in Kubernetes cluster we need to access the API and go through three main steps:

• Authentication
• Authorisation (RBAC or ABAC)
• Admission Control

See the official documentation for more details:

Authentication

• Authentication is done with certificates, tokens or basic auth
• Users are not created by the API and should be managed by external system
• Service accounts are used by processes to access the API (a service account provides an identity for processes than run in a pod)

Authorisation

Once a request is authenticated, it needs to be authorised to be able to proceed through the Kubernetes system. There are three main modes of authorisation:

• ABAC (attribute based access control)
• RBAC (role based access control)
• WebHook

Admission Controller

Accesses the contents of the objects being created by the requests. It can modify the content or validate it and potentially deny the request.

Security Context

A security context defines privilege and access control settings for a Pod or Container so we can limit what processes running in containers can do. For example we can limit:

• the user ID of the process (UID)
• the Linux capabilities
• filesystem groups

If we want to enforce that containers cannot run their process as root user we can add runAsNonRoot: true to the pod spec. Or we can define a PodSecurityPolicy to that effect.

To automate the enforcement of security contexts, we can define PodSecurityPolicies (PSP)

Pod Security Policies are cluster-level rules that govern what a pod can do, what they can access, what user they run as...

For a PSP to be enabled we must first configure the admission controller of the controller-manager to contain PodSecurityPolicy.

Network Security Policy

A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.

NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.