Security Context — Kubernetes

A security context defines privilege and access control settings for a Pod or Container.

Pod Security Standards

Pod Security Standards are a set of standards that cover the security spectrum at a high level. The three primary standards are:

1. Privileged → Open and unrestricted
2. Baseline → Minimally restrictive policy, allowing the default pod configuration.
3. Restricted → Highly restricted, covering best practices. May cause compatibility issues

Each of these policies define which fields are restricted within a Pod specification and the allowed values.

• spec.containers[*].ports
• spec.volumes[*].hostPath
• spec.securityContext
• spec.containers[*].securityContext

More https://kubernetes.io/docs/concepts/security/pod-security-standards/

Policy Modes

Policies are applied using modes

• enforce — Any Pods that violate the policy will be rejected
• audit — Pods with violations will be allowed and an audit annotation will be added
• warn — Pods that violate the policy will be allowed and a warning message will be sent back to the user.

Pod Security Admission

Pod Security Admission defines isolation levels for Pods. Essentially, it lets you define how you want your security to look for Pods running inside your environment.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

The Pod Security Admission puts requirements on said security context based on the Pod Security Standards (Privileged, Baseline, and Restricted).

API Access Control

1. Authentication
2. Admission Controllers
3. Authorization
4. Certificate signing
5. Service accounts
6. Kubelet authentication

RBAC

RBAC is to ensure that users, teams, and service accounts have the PROPER permissions

1. Least privilege.
2. Minimize distribution of privileged tokens.
3. Constantly review permissions for users.

Secrets

You can use the resource to create secrets that contain any information you don’t want as plain-text. This can be passwords, API keys, and anything else that you don’t want in plain-text.

Multitenancy

“Singletenancy” perspective, it would mean one user per cluster or one application per cluster. From a “multitenancy” perspective, it means multiple users or a team on a cluster or multiple applications.

Cluster Security

cluster level in the cloud, because it’s managed by the cloud, it really all comes down to giving proper permissions and access.

A few other cluster-specific security protocols to think about are:

1. Limiting resource usage on the cluster.
2. Security Contexts in your Pod spec.
3. Restricting network access.
4. Audit logging enabled.

From an application perspective, it comes down to three parts:

1. Access to the application.
2. What Pods have access to from a network perspective.
3. Proper encryption.

Code Security

1. TLS access for any communication that needs to occur via TCP/IP.
2. Ensure that the apps only have access to particular ports that are necessary.
3. Scan your code with a third-party tool (like Sonarqube) and utilize Static Code Analysis.
4. Test out attacks against your code in a controlled environment using dynamic probing.

Kubernetes security contexts define runtime security settings for pods or containers. If no security context is specified, Kubernetes applies a default one, which may not meet requirements. You can add securityContext field in the pod manifest file to set up security contexts at the pod or container level.

See the

1. Pod level
2. Container level
3. Pod level + Container level
4. Container level : Capabilities

POD Level 👇🏻

SecurityContext field has been defined at the Pod level with the runAsUser and fsGroup properties set to 1000 and 2000 respectively. Therefore, both containers will run as the user with UID 1000 and have access to the group with GID 2000.

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
securityContext:
runAsUser: 1000
fsGroup: 2000
containers:
- name: container1
image: nginx
- name: container2
image: busybox

Container level 👇🏻

SecurityContext specified at the container level only apply to the individualcontainer, not to other containers in the pod.

apiVersion: v1
kind: Pod
metadata:
name: mypod
Spec:
containers:
- name: container1
image: nginx
securityContext:
runAsUser: 1000
- name: container2
image: busybox
securityContext:
runAsUser: 2000

Pod level + Container level 👇🏻

SecurityContext sets at the container level always override those set at the pod level.

apiVersion: v1
kind: Dod
metadata:
name: mypod
spec:
pod-level....» securityContext:
runAsUser: 1000
containers:
- name: my-container
image: my-image
container-leve.......>seCurityContext:
runAsUser: 2000

Container level : Capabilities 👇🏻

Set capabilities for a container. capabilities can NOT be specified at the pod level.

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: my-container
image: my-image
securityContext:
capabilities:
add: ["NET_ADMIN"]