security policy

In today's world, security risks are low or minimal thanks to many third-party tools improving security. What if we take on policies preventing any Kubernetes cluster from being attacked? The policies are much more supportive and independent, rather than relying on various vendor tools. They simplify the essential measures needed to ensure that your cluster is safe. They can be used to control access to resources, limit the privileges of users, and enforce security best practices. This will save you hence from spending a lot of money and investing on looking for other tools.

This blog post explores the essential security policies needed for any Kubernetes cluster and how they empower users to overcome various challenges. We'll delve into several types of security policies that you can implement in your Kubernetes cluster to demonstrate their effectiveness.

First, we will look at Network Policies, which control the communication between different pods and services within the cluster. By defining these policies, you can ensure that only authorized traffic is allowed, thereby reducing the risk of unauthorized access and potential breaches.

Next, we will discuss Security Contexts, which are crucial for defining the security settings for pods and containers in your Kubernetes cluster.

Additionally, we will also cover Role-Based Access Control (RBAC), which is crucial for managing user permissions and access to cluster resources. By setting up RBAC, you can define roles and assign them to users or groups, ensuring that individuals only have the permissions necessary for their tasks. This minimises the risk of accidental or malicious actions that could compromise the cluster.

Finally, we will discuss Pod Security Standards. These policies help you enforce security standards at the pod level running in Kubernetes. Implementing the policies can significantly enhance the security posture of your cluster by ensuring that pods operate within defined security boundaries

By the end of this post, you will have a comprehensive understanding of the various security policies available for Kubernetes clusters and how to implement them effectively to safeguard your infrastructure.

Introducing Network Policy

Network policies allow you to control the flow of traffic in and out of your cluster. You can use them to block incoming traffic to certain pods, or to restrict outgoing traffic from pods. Let's follow the best practices that need to be put in place.

Best Practices:

Deny All Traffic by Default: Start with a default deny-all policy and then explicitly allow necessary traffic.
Micro-Segmentation: Define network policies that segment the network at a granular level, allowing only necessary communications.
Isolation: Use network policies to isolate different environments (e.g., development, staging, production) and sensitive applications.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

In this example, a network policy is used to control traffic between different components of an application. Specifically, the policy allows only ingress traffic to pods labeled with role: db from pods labeled with role: frontend.

This segregation is essential for applications with multiple tiers (e.g., frontend, backend, database). By explicitly allowing traffic only between specific components, you reduce the risk of unauthorized access and potential data breaches. It also helps in minimizing the blast radius in case of a compromised pod, as the attacker cannot freely communicate with other pods in the cluster.

Next Security Contexts

Security Contexts allow you to define privilege and access control settings for pods and containers.

Best Practices:

Restrict Privileged Containers: Prevent containers from running in privileged mode unless absolutely necessary.
Limit Capabilities: Restrict the capabilities that a container can add to its default set.
Read-Only Filesystem: Enforce read-only root file systems for containers to prevent tampering.
Run As Non-Root: Ensure containers run as non-root users to minimise potential damage from a compromise.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      runAsUser: 1000
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true

In this example, a security context is applied to a pod to enforce security best practices. The pod is configured to run as a non-root user (user ID 1000), which helps mitigate the risk of privilege escalation attacks. By setting allowPrivilegeEscalation: false, the container is prevented from gaining additional privileges. Dropping all capabilities and setting the root filesystem as read-only further restricts the pod’s ability to make unauthorised changes or perform potentially harmful actions.

This configuration is particularly useful in multi-tenant environments where different teams or applications share the same Kubernetes cluster. It ensures that even if a container is compromised, the impact is minimised, and the attacker cannot easily escalate their privileges or modify the container’s filesystem.

RBAC (Role-Based Access Control)

RBAC manages permissions and access control in Kubernetes.

Best Practices:

Principle of Least Privilege: Grant the minimum permissions necessary for users and services to perform their tasks.
Role and RoleBinding: Use these to define permissions within a namespace.
ClusterRole and ClusterRoleBinding: Use these to define permissions cluster-wide.
Review and Audit: Regularly review RBAC policies and audit permissions to ensure they are still appropriate.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name of the user to bind to this role
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This RBAC example grants a user named jane read-only access to pods in the default namespace. By defining a Role with specific permissions (get, watch, list) and binding this role to the user via a RoleBinding, Kubernetes administrators can enforce the principle of least privilege.

This use case is crucial in large organizations where multiple users and teams interact with the Kubernetes cluster. It ensures that users have only the permissions necessary for their roles, reducing the risk of accidental or malicious changes to the cluster's state.

Pod Security Standards (PSS)

Pod Security Standards offers three built-in profiles: privileged, baseline, and restricted. These standards help ensure that pods adhere to predefined security configurations, reducing the risk of security vulnerabilities. Here’s how you can apply these policies using namespace labels. Let's dive into it.

Applying Pod Security Standards Using Pod Security Admission

Pod Security Admission enables the enforcement of these profiles by labelling namespaces accordingly.

Example 1: Applying the Restricted Profile

For workloads that handle sensitive data or operate in high-security environments, using the restricted security level ensures maximum security constraints are applied.

apiVersion: v1
kind: Namespace
metadata:
  name: high-security
  labels:
    pod-security.kubernetes.io/enforce: "restricted"
    pod-security.kubernetes.io/audit: "baseline"
    pod-security.kubernetes.io/warn: "baseline"

Enforces the restricted policy, ensuring no privileged containers or host network access.
Audits and warns for configurations that meet the baseline level but do not meet restricted standards.

Example 2: Applying the Baseline Profile

For general-purpose applications where some elevated privileges might be required, but overall security is still important.

apiVersion: v1
kind: Namespace
metadata:
  name: general-purpose
  labels:
    pod-security.kubernetes.io/enforce: "baseline"
    pod-security.kubernetes.io/audit: "privileged"
    pod-security.kubernetes.io/warn: "privileged"

Enforces the baseline policy, which restricts some high-risk configurations but allows typical application use cases.
Audits and warns for configurations that meet the privileged level but do not meet baseline standards.

Example 3: Applying the Privileged Profile

For legacy applications or workloads that require elevated privileges, using the privileged security level allows maximum flexibility.

apiVersion: v1
kind: Namespace
metadata:
  name: legacy-apps
  labels:
    pod-security.kubernetes.io/enforce: "privileged"

Enforces the privileged policy, allowing the use of privileged containers, host networking, and other elevated permissions.

By leveraging these policies, Kubernetes administrators can significantly enhance the security posture of their clusters, protect sensitive data, and ensure compliance with industry standards.

Thanks for reading by!!!

Let's checkout your knowledge what we have got you covered the essential topics in terms of security.

What is the primary purpose of controlling egress traffic in a Network Policy?

A) To prevent pods from scheduling on specific nodes
B) To control the outgoing traffic from pods to external destinations
C) To manage user access to the Kubernetes cluster
D) To define the storage requirements for pods

What doesprivileged: true mean when defined in a security context?

A) The container has access to all the capabilities of the host
B) The container is restricted from accessing host resources
C) The container is running with non-root user privileges
D) The container is prevented from making outbound network connections

When therunAsUser ID is set to 0, what does that mean?

A) The container runs as a non-root user
B) The container runs with elevated privileges as the root user
C) The container is restricted from accessing the network
D) The container is limited to read-only file system access

In Kubernetes RBAC, what is the purpose of a RoleBinding?

A) To define network policies for a namespace
B) To bind roles to users, groups, or service accounts
C) To configure pod security contexts
D) To manage node resources

Which resource is used in RBAC to specify the permissions a user or group has?

A) ConfigMap
B) NetworkPolicy
C) Role or ClusterRole
D) PodSecurityPolicy

Which label is used to block privileged pods at the namespace level?

A) pod-security.kubernetes.io/enforce: "privileged"
B) privileged: "false"
C) pod-security.kubernetes.io/enforce: "baseline"
D) pod-security.kubernetes.io/enforce: "deny"

Comment down your answers below. It was a fun experience really. Isn't it?

These questions cover the fundamental concepts and specific details about Network Policies, Pod Security Standards, and Role-Based Access Control (RBAC) in Kubernetes. Understanding these concepts is crucial for managing the security of a Kubernetes cluster effectively.

References:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

https://kubernetes.io/docs/concepts/services-networking/network-policies/

https://kubernetes.io/docs/concepts/security/rbac-good-practices/

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

Essential Security Policies for a Safe Kubernetes Cluster

Introducing Network Policy

Next Security Contexts

RBAC (Role-Based Access Control)

Pod Security Standards (PSS)

Example 1: Applying the Restricted Profile

References: