Pod Security Policies (PSPs) are a critical aspect of Kubernetes security, providing a mechanism to control the security-related aspects of pod specifications. They allow cluster administrators to define a set of conditions that a pod must meet to be accepted into the system, thus enhancing the security posture of the Kubernetes cluster.
Key Concepts
- Pod Security Policy (PSP): A cluster-level resource that controls security-sensitive aspects of the pod specification.
- Admission Controller: A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
- Security Context: Defines privilege and access control settings for a pod or container.
Creating a Pod Security Policy
Example PSP YAML
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example-psp spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'MustRunAsNonRoot' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: - min: 1 max: 65535
Explanation
- privileged: Ensures that no privileged containers are allowed.
- allowPrivilegeEscalation: Prevents containers from gaining more privileges than their parent process.
- requiredDropCapabilities: Drops all Linux capabilities.
- volumes: Restricts the types of volumes that can be used.
- hostNetwork, hostIPC, hostPID: Prevents the use of the host's network, IPC, and PID namespaces.
- runAsUser: Ensures that containers run as a non-root user.
- seLinux: Allows any SELinux context.
- supplementalGroups: Requires that containers run with a specific range of supplemental groups.
- fsGroup: Requires that containers run with a specific range of file system groups.
Applying the Pod Security Policy
-
Create the PSP:
kubectl apply -f example-psp.yaml
-
Create a Role and RoleBinding: To use the PSP, you need to create a Role and RoleBinding that grants the necessary permissions.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: psp-role namespace: default rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: ['example-psp']
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: psp-rolebinding namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: psp-role subjects: - kind: User name: <your-username> apiGroup: rbac.authorization.k8s.io
-
Apply the Role and RoleBinding:
kubectl apply -f psp-role.yaml kubectl apply -f psp-rolebinding.yaml
Practical Exercise
Task
-
Create a Pod Security Policy that:
- Disallows privileged containers.
- Requires containers to run as a non-root user.
- Restricts volume types to
configMap
andemptyDir
.
-
Apply the PSP and create a Role and RoleBinding to use it.
Solution
-
Create the PSP YAML:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: custom-psp spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - 'configMap' - 'emptyDir' hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'MustRunAsNonRoot' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: - min: 1 max: 65535
-
Apply the PSP:
kubectl apply -f custom-psp.yaml
-
Create the Role and RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: custom-psp-role namespace: default rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: ['custom-psp']
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: custom-psp-rolebinding namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: custom-psp-role subjects: - kind: User name: <your-username> apiGroup: rbac.authorization.k8s.io
-
Apply the Role and RoleBinding:
kubectl apply -f custom-psp-role.yaml kubectl apply -f custom-psp-rolebinding.yaml
Common Mistakes and Tips
- Incorrect RoleBinding: Ensure that the RoleBinding correctly references the Role and the PSP.
- PSP Not Applied: Verify that the PSP is applied and active by checking the
kubectl get psp
output. - Admission Controller: Ensure that the PodSecurityPolicy admission controller is enabled in your Kubernetes cluster.
Conclusion
Pod Security Policies are a powerful tool for enforcing security standards in your Kubernetes cluster. By defining and applying PSPs, you can control the security aspects of your pods, ensuring they adhere to your organization's security policies. This module has covered the creation, application, and management of PSPs, providing you with the knowledge to enhance your cluster's security.
Kubernetes Course
Module 1: Introduction to Kubernetes
- What is Kubernetes?
- Kubernetes Architecture
- Key Concepts and Terminology
- Setting Up a Kubernetes Cluster
- Kubernetes CLI (kubectl)
Module 2: Core Kubernetes Components
Module 3: Configuration and Secrets Management
Module 4: Networking in Kubernetes
Module 5: Storage in Kubernetes
Module 6: Advanced Kubernetes Concepts
Module 7: Monitoring and Logging
- Monitoring with Prometheus
- Logging with Elasticsearch, Fluentd, and Kibana (EFK)
- Health Checks and Probes
- Metrics Server
Module 8: Security in Kubernetes
Module 9: Scaling and Performance
Module 10: Kubernetes Ecosystem and Tools
Module 11: Case Studies and Real-World Applications
- Deploying a Web Application
- CI/CD with Kubernetes
- Running Stateful Applications
- Multi-Cluster Management