Enabling pod security policies

By enabling pod security policies, you make sure that compromised namespaces (other than istio-system) don't impact the security of other namespaces that are sharing the same nodes. Sample PodSecurityPolicy resource files that work with Mesh CA are provided with Anthos Service Mesh. You can modify these files as needed. In the following, you first apply the pod security policies, and then enable the pod security policy for the GKE cluster.

Enabling pod security policies

Check if your system already has pod security policies defined:
```
kubectl get psp --all-namespaces
```
- If the command returns a list of existing policies, your system already has pod security policies applied. We recommend that you have your existing PodSecurityPolicy YAML files available in case you need to do a rollback. You need to add the following section to the spec part in each of your existing pod security policies, except the ones starting with gce.
```
allowedHostPaths:
  - pathPrefix: "/var/run/sds"
    readOnly: true
allowedCapabilities:
  - NET_ADMIN
  - NET_RAW
```
  These lines allow reading from the /var/run/sds host path, and allow automatic sidecar injection.
  
  You can use kubectl to edit and apply the pod security policies in Kubernetes:
```
kubectl edit psp YOUR_EXISTING_POD_SECURITY_POLICY
```
- If the command returns No resources found, you don't have a pod security policy defined. You might still need to modify the samples/security/psp/all-pods-psp.yaml file to make sure it doesn't conflict with your existing workloads. For more details, see the Pod Security Policy guide. After modifying the file, apply it:
```
kubectl apply -f "samples/security/psp/all-pods-psp.yaml"
```
Warning: If the pod security policy is not configured to allow the permissions needed by your workloads, your workloads might fail to be created.
Apply the pod security policy to secure the Secret Discovery Service (SDS):
```
kubectl apply -f "samples/security/psp/citadel-agent-psp.yaml"
```
This gives the Citadel agent (also referred to as the Node Agent) the privilege to create the UDS path /var/run/sds on the host VM.
Run the following command to enable the pod security policy:
```
gcloud beta container clusters update ${CLUSTER_NAME} \
    --enable-pod-security-policy
```
Enabling the pod security policies might take several minutes. During this process, existing workloads won't be able to connect to the Kubernetes master. Wait until the Kubernetes master is up again. You can check the cluster status in the Google Cloud console on the Kubernetes clusters page.

For more information, see Using pod security policies.

Verifying pod security policies

If you have existing workloads, we recommend that you verify that the workloads can be deployed with the new pod security policies.

Pick deployments that you want to check and increase their replicas. For example, if the specified service has 1 replica, then increase it by 1:
```
kubectl scale deployment YOUR_DEPLOYMENT --replicas=2 -n YOUR_NAMESPACE
```
Verify that the deployment scales up:
```
kubectl get deploy
```

Verify that the new workload can be deployed. This means that the pod security policy doesn't impact the deployment of a workload for the service.

kubectl get deployment YOUR_SERVICE -n YOUR_NAMESPACE
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
YOUR_SERVICE            2/2     2            2           ...

Scale down the replicas of the service:

kubectl scale deployment YOUR_SERVICE --replicas=1 -n YOUR_NAMESPACE

If your workloads don't successfully deploy, you can temporarily disable the pod security policy while fixing the YAML files:
```
gcloud beta container clusters update ${CLUSTER_NAME} \
  --no-enable-pod-security-policy
```

Enabling pod security policies

Enabling pod security policies

Verifying pod security policies

What's next