Profile Applicability:

  • Level 2

Description:
 A security context in Kubernetes defines privilege and access control settings for a Pod or Container. Applying security contexts to your Pods and Containers ensures that they run with the least privileges required, helping to secure your workloads. This check ensures that proper security contexts are applied, including settings like user and group IDs, privilege escalation, and access to host resources.

Rationale:
 By specifying a security context for your Pods and Containers, you can enforce security policies that control resource access, restrict privileged actions, and mitigate security risks. For example, running containers as non-root users and ensuring that privileged escalation is disabled helps minimize potential attack vectors.

Impact:

  • Pros:

    • Enhances the security posture of your Kubernetes environment.

    • Limits the potential impact of container compromise by enforcing least privilege.

    • Allows more granular control over container behaviors and interactions with the host system.

  • Cons:

    • Requires more configuration effort and careful consideration of security needs.

    • May cause compatibility issues with applications that require higher privileges.

Default Value:
 By default, Kubernetes allows containers to run with root privileges unless explicitly configured with a security context to restrict them.

Pre-requisites:
 Ensure that security policies, such as RBAC and PodSecurityPolicies, are configured to support the use of security contexts in your Kubernetes environment.

Remediation

Test Plan:

Using Azure Console:

  1. Navigate to the Azure portal and review the Kubernetes cluster settings.

  2. Verify if security contexts are defined for the Pods and Containers by inspecting the Pod specifications.

  3. Ensure that containers are not running with unnecessary privileges, and check for the application of user and group IDs.

Using Azure CLI:

  1. List the Pods in your cluster to check for security context usage:

     kubectl get pods --all-namespaces -o=jsonpath='{.items[*].spec.securityContext}'

  2. Ensure that the securityContext field is properly defined, especially runAsUser, runAsGroup, and allowPrivilegeEscalation.

Implementation Plan:

Using Azure Console:

  1. In the Azure portal, navigate to your AKS cluster and review the security context configurations.

  2. Modify the Pod specification to apply the appropriate security context, ensuring that containers run as non-root users and that privilege escalation is disabled.

  3. Ensure other settings like fsGroup, runAsNonRoot, and allowPrivilegeEscalation are configured according to the security requirements of the application.

Using Azure CLI:

  1. Edit the Pod specification to define a security context:

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      runAsNonRoot: true

  1. Apply the security context to the Pod with the following command:

     kubectl apply -f pod-spec.yaml

Backout Plan:

Using Azure Console:

  1. If the security context causes issues with application functionality, revert the configuration in the Azure portal by modifying or removing the security context.

Using Azure CLI:

  1. Revert the changes by editing the Pod specification to remove or modify the security context as needed:

     kubectl edit pod <pod-name> --namespace=<namespace>

  2. Set the security context fields back to their default state if necessary.

References:

  1. Kubernetes Security Context Documentation

  2. Azure Kubernetes Service (AKS) Security Best Practices

  3. Kubernetes Pod Security Policies