Using PodSecurityPolicies

Beta

This is a Beta release of PodSecurityPolicies in Google Kubernetes Engine. This feature is not covered by any SLA or deprecation policy and might be subject to backward-incompatible changes.

This page explains how to use PodSecurityPolicies in Google Kubernetes Engine.

Overview

A PodSecurityPolicy is an admission controller resource you create that validates requests to create and update Pods on your cluster. The PodSecurityPolicy defines a set of conditions that Pods must meet to be accepted by the cluster; when a request to create or update a Pod does not meet the conditions in the PodSecurityPolicy, that request is rejected and an error is returned.

To use PodSecurityPolicy, you must first create and define policies that new and updated Pods must meet. Then, you must enable the PodSecurityPolicy admission controller, which validates requests to create and update Pods against the defined policies.

When multiple PodSecurityPolicies are available, the admission controller uses the first policy that successfully validates. Policies are ordered alphabetically, and the controller prefers non-mutating policies (policies that don't change the Pod) over mutating policies.

PodSecurityPolicy is available in GKE clusters running Kubernetes version 1.8.6 or later.

Before you begin

To prepare for this task, perform the following steps:

• Ensure that you have enabled the Google Kubernetes Engine API.
Enable Google Kubernetes Engine API
• Ensure that you have installed the Cloud SDK.
• Set your default project ID:

  gcloud config set project [PROJECT_ID]

• If you are working with zonal clusters, set your default compute zone:

  gcloud config set compute/zone [COMPUTE_ZONE]

• If you are working with regional clusters, set your default compute region:

  gcloud config set compute/region [COMPUTE_REGION]

• Update gcloud to the latest version:

  gcloud components update

Note: You can override these default settings in gcloud commands using the --project, --zone, and --region operational flags.

• Ensure that you understand how to use role-based access control in GKE.

Defining PodSecurityPolicies

You need to define PodSecurityPolicy resources in your cluster before the PodSecurityPolicy controller can validate and accept Pods into the cluster.

PodSecurityPolicies specify a list of restrictions, requirements, and defaults for Pods created under the policy. Examples include restricting the use of privileged containers, hostPath volumes, and host networking, or defaulting all containers to run with a seccomp profile. The PodSecurityPolicy admission controller validates requests against available PodSecurityPolicies.

The following example PodSecurityPolicy, my-psp.yaml, simply prevents the creation of privileged Pods. The policy also affects several other control aspects, such as allowing access to all available volumes:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-psp
spec:
  privileged: false  # Prevents creation of privileged Pods
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Note: privileged: false is not sufficient for preventing Pods from performing privileged operations. For more comprehensive restrictions, refer to the example restricted policy in Example Policies.

The PodSecurityPolicy specification can secure numerous control aspects. The control aspects specified in this example—seLinux, supplementalGroups, runAsUser, and fsGroup—are all set to RunAsAny, indicating that any valid values for these fields can be used with this policy.

For more information about PodSecurityPolicies and their control aspects, refer to What is a Pod Security Policy? and the policy reference in the Kubernetes documentation.

You create this resource using the kubectl command-line tool:

kubectl apply -f my-psp.yaml

For more examples of configuring PodSecurityPolicies, refer to Example on the PodSecurityPolicy page of the Kubernetes documentation.

Authorizing policies

Accounts with the cluster-admin role can use role-based access control to create a Role or ClusterRole that grants the desired service accounts access to PodSecurityPolicies. A ClusterRole grants cluster-wide permissions, and a Role grants permissions within a namespace that you define.

For example, the following ClusterRole, my-clusterrole.yaml, grants access to the my-psp PodSecurityPolicy, as indicated by verb: use:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: my-clusterrole
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - my-psp
  verbs:
  - use

Create the ClusterRole by running the following command:

kubectl apply -f my-clusterrole.yaml

After creating a Role (or ClusterRole), you associate it with the desired service accounts by creating a RoleBinding (or ClusterRoleBinding) resource.

The following RoleBinding, my-rolebinding.yaml, binds the ClusterRole, my-clusterrole, to the service accounts in a specific namespace, my-namespace:

# Bind the ClusterRole to the desired set of service accounts.
# Policies should typically be bound to service accounts in a namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-rolebinding
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: my-clusterrole
subjects:
# Example: All service accounts in my-namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
# Example: A specific service account in my-namespace
- kind: ServiceAccount # Omit apiGroup
  name: default
  namespace: my-namespace

In this RoleBinding:

• The subjects field specifies to which accounts the ClusterRole is bound.
• The first subject is a Group, system:serviceaccounts, which encompasses all service accounts in the cluster.
• The second subject is an individual ServiceAccount, default, which specifies the default service account in the namespace.

Create the RoleBinding by running the following command:

kubectl apply -f my-rolebinding.yaml

For more information about RBAC, refer to Using RBAC Authorization.

Enabling PodSecurityPolicy controller

To use the PodSecurityPolicy admission controller, you must create a new cluster or update an existing cluster with the --enable-pod-security-policy flag.

Warning: If you enable the PodSecurityPolicy controller without first defining and authorizing any actual policies, no users, controllers, or service accounts can create or update Pods. If you are working with an existing cluster, you should define and authorize policies before enabling the controller.

To create a new cluster with PodSecurityPolicy, run the following command:

gcloud beta container clusters create [CLUSTER_NAME] --enable-pod-security-policy

To update an existing cluster:

gcloud beta container clusters update [CLUSTER_NAME] --enable-pod-security-policy

Disabling PodSecurityPolicy controller

You disable the PodSecurityPolicy controller by running the following command:

gcloud beta container clusters update [CLUSTER_NAME] --no-enable-pod-security-policy

Disabling the controller causes the cluster to stop validating and defaulting existing policies, but does not delete them. Bindings are also not deleted.

Working with NetworkPolicy

If you are using a NetworkPolicy, and you have a Pod that is subject to a PodSecurityPolicy, create an RBAC Role or ClusterRole that has permission to use the PodSecurityPolicy. Then bind the Role or ClusterRole to the Pod's service account. Granting permissions to user accounts is not sufficient in this case. For more information, see Authorizing policies.

What's next

• Learn more about role-based access control.
• Learn about securing your cluster using identity and access management.
• Learn about Sandbox Pods