Try Kubernetes

Reference Documentation

Design docs, concept definitions, and references for APIs and CLIs.

Documentation for Kubernetes v1.5 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

Reference Documentation
Kubernetes Resource Types (New Docs Style)
Version 1.5
Kubernetes API (New Docs Style)
Version 1.5
Kubectl Commands (New Docs Style)
Version 1.5
Kubernetes API
Kubernetes API Overview
Accessing the API
Overview
Authenticating
Using Authorization Plugins
Using Admission Controllers
Managing Service Accounts
Kubernetes API Operations
Kubernetes API Definitions
Well-Known Labels, Annotations and Taints
Kubernetes API Swagger Spec
Autoscaling API
Autoscaling API Operations
Autoscaling API Definitions
Batch API
Batch API Operations
Batch API Definitions
Apps API
Apps API Operations
Apps API Definitions
Extensions API
Extensions API Operations
Extensions API Definitions
kubectl CLI
kubectl Overview
kubectl for Docker Users
kubectl Usage Conventions
JSONpath Support
kubectl Cheat Sheet
kubectl Commands
kubectl
kubectl annotate
kubectl api-versions
kubectl apply
kubectl attach
kubectl autoscale
kubectl certificate
kubectl certificate approve
kubectl certificate deny
kubectl cluster-info
kubectl cluster-info dump
kubectl completion
kubectl config
kubectl config current-context
kubectl config delete-cluster
kubectl config delete-context
kubectl config get-clusters
kubectl config get-contexts
kubectl config set-cluster
kubectl config set-context
kubectl config set-credentials
kubectl config set
kubectl config unset
kubectl config use-context
kubectl config view
kubectl convert
kubectl cordon
kubectl cp
kubectl create
kubectl create configmap
kubectl create deployment
kubectl create namespace
kubectl create quota
kubectl create secret docker-registry
kubectl create secret
kubectl create secret generic
kubectl create secret tls
kubectl create serviceaccount
kubectl create service clusterip
kubectl create service loadbalancer
kubectl create service nodeport
kubectl delete
kubectl describe
kubectl drain
kubectl edit
kubectl exec
kubectl explain
kubectl expose
kubectl get
kubectl label
kubectl logs
kubectl options
kubectl patch
kubectl port-forward
kubectl proxy
kubectl replace
kubectl rolling-update
kubectl rollout
kubectl rollout history
kubectl rollout pause
kubectl rollout resume
kubectl rollout status
kubectl rollout undo
kubectl run
kubectl scale
kubectl set
kubectl set image
kubectl set resources
kubectl taint
kubectl top
kubectl top node
kubectl top pod
kubectl uncordon
kubectl version
Superseded and Deprecated Commands
kubectl stop
Kubernetes Components
kube-apiserver
kube-controller-manager
kube-proxy
kube-scheduler
kubelet
Overview
Master-Node communication
TLS bootstrapping
Kubelet authentication/authorization
Glossary
Annotations
Daemon Sets
Deployments
Horizontal Pod Autoscaling
Images
Ingress Resources
Jobs
Names
Namespaces
Network Policies
Nodes
Persistent Volumes
Pet Sets
Pods
Pod Security Policies
Replica Sets
Replication Controller
Resource Quotas
Cron Jobs
Secrets
Security Context
Services
Service Accounts
Third Party Resources
Volumes
Kubernetes Design Docs
Kubernetes Architecture
Kubernetes Design Overview
Kubernetes Identity and Access Management
Kubernetes OpenVSwitch GRE/VxLAN networking
Security Contexts
Security in Kubernetes

Edit This Page

Pod Security Policies

Objects of type PodSecurityPolicy govern the ability to make requests on a pod that affect the SecurityContext that will be applied to a pod and container.

See PodSecurityPolicy proposal for more information.

What is a Pod Security Policy?

A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. They allow an administrator to control the following:

  1. Running of privileged containers.
  2. Capabilities a container can request to be added.
  3. The SELinux context of the container.
  4. The user ID.
  5. The use of host namespaces and networking.
  6. Allocating an FSGroup that owns the pod’s volumes
  7. Configuring allowable supplemental groups
  8. Requiring the use of a read only root file system
  9. Controlling the usage of volume types

Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to. These settings fall into three categories:

Strategies

RunAsUser

SELinuxContext

SupplementalGroups

FSGroup

Controlling Volumes

The usage of specific volume types can be controlled by setting the volumes field of the PSP. The allowable values of this field correspond to the volume sources that are defined when creating a volume:

  1. azureFile
  2. azureDisk
  3. flocker
  4. flexVolume
  5. hostPath
  6. emptyDir
  7. gcePersistentDisk
  8. awsElasticBlockStore
  9. gitRepo
  10. secret
  11. nfs
  12. iscsi
  13. glusterfs
  14. persistentVolumeClaim
  15. rbd
  16. cinder
  17. cephFS
  18. downwardAPI
  19. fc
  20. configMap
  21. vsphereVolume
  22. quobyte
  23. photonPersistentDisk
  24. projected
  25. portworxVolume
  26. scaleIO
  27. * (allow all volumes)

The recommended minimum set of allowed volumes for new PSPs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, and secret.

Host Network

Admission

Admission control with PodSecurityPolicy allows for control over the creation and modification of resources based on the capabilities allowed in the cluster.

Admission uses the following approach to create the final security context for the pod:

  1. Retrieve all PSPs available for use.
  2. Generate field values for security context settings that were not specified on the request.
  3. Validate the final settings against the available policies.

If a matching policy is found, then the pod is accepted. If the request cannot be matched to a PSP, the pod is rejected.

A pod must validate every field against the PSP.

Creating a Pod Security Policy

Here is an example Pod Security Policy. It has permissive settings for all fields

psp.yaml 
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: permissive
spec:
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  hostPorts:
  - min: 8000
    max: 8080
  volumes:
  - '*'

Create the policy by downloading the example file and then running this command:

$ kubectl create -f ./psp.yaml
podsecuritypolicy "permissive" created

Getting a list of Pod Security Policies

To get a list of existing policies, use kubectl get:

$ kubectl get psp
NAME        PRIV   CAPS  SELINUX   RUNASUSER         FSGROUP   SUPGROUP  READONLYROOTFS  VOLUMES
permissive  false  []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*]
privileged  true   []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*]
restricted  false  []    RunAsAny  MustRunAsNonRoot  RunAsAny  RunAsAny  false           [emptyDir secret downwardAPI configMap persistentVolumeClaim]

Editing a Pod Security Policy

To modify policy interactively, use kubectl edit:

$ kubectl edit psp permissive

This command will open a default text editor where you will be ably to modify policy.

Deleting a Pod Security Policy

Once you don’t need a policy anymore, simply delete it with kubectl:

$ kubectl delete psp permissive
podsecuritypolicy "permissive" deleted

Enabling Pod Security Policies

In order to use Pod Security Policies in your cluster you must ensure the following

  1. You have enabled the api type extensions/v1beta1/podsecuritypolicy
  2. You have enabled the admission controller PodSecurityPolicy
  3. You have defined your policies

Working With RBAC

In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. Access to different PodSecurityPolicy objects can be controlled via authorization. To limit access to PodSecurityPolicy objects for pods created via a Deployment, ReplicaSet, etc, the Controller Manager must be run against the secured API port, and must not have superuser permissions.

PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. For more details, see the PodSecurityPolicy RBAC example of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly.

Analytics

Create an Issue Edit this Page