Skip to content

Contact sales

By filling out this form and clicking submit, you acknowledge our privacy policy.
  • Labs icon Lab
  • A Cloud Guru
Google Cloud Platform icon

Kubernetes with kops for PodSecurityPolicy Lab

This lab guides the student through a step-by-step hands-on example of creating a pod security policy, testing it, and using role bindings to enable it to prevent privileged pods.

Google Cloud Platform icon

Path Info

Clock icon Beginner
Clock icon 1h 0m
Clock icon Apr 05, 2019

Contact sales

By filling out this form and clicking submit, you acknowledge our privacy policy.

Table of Contents

  1. Challenge

    Use Kops to Create the Cluster

    From the bastion host, use kops to create a cluster:

    Use the terminal emulator or SSH to gain access to the 'Bastion Host' Cloud Server server instantiated for the lab.

    ssh cloud_user@[IP Address of Bastion Host]

    Once you have access you should be able to do a ls -l and see the

    ls -l

    Execute the script to create the cluster configuration files.

    . ./

    Note: Answer any prompts as needed.

    Use kops to edit the cluster configuration. Use esc then :wq! to save your changes.

    kops edit cluster

    Under the spec: for the cluster, add the following lines.

        - NamespaceLifecycle
        - LimitRanger
        - ServiceAccount
        - PersistentVolumeLabel
        - DefaultStorageClass
        - ResourceQuota
        - PodSecurityPolicy
        - DefaultTolerationSeconds

    The display above has tabs, but you should normally use just two spaces to indent lines. The file should remain the same from the next line to the end.

    After editing the cluster configuration to add the admission controller, use kops to update the cluster and create the nodes.

    kops update cluster --name=$KOPS_CLUSTER_NAME --yes

    Copy the command at the bottom to connect to the master node using SSH.

    Note: It will take several minutes to validate the cluster, which you can check with: kops validate cluster.

  2. Challenge

    Create Namespace, Serviceaccount, and Rolebinding

    Create the psp-ns namespace.

    kubectl create namespace psp-ns

    Create the psp-sa serviceaccount within the psp-ns namespace.

    kubectl create serviceaccount -n psp-ns psp-sa

    Create a rolebinding binding the cluster role verb edit to the service account psp-sa.

    kubectl create rolebinding -n psp-ns rb-id --clusterrole=edit --serviceaccount=psp-ns:psp-sa

    Now for convenience, create an alias for the psp-admin within the namespace.

    alias psp-admin='kubectl -n psp-ns'

    And create an alias for the psp-user within the namespace.

    alias psp-user='kubectl --as=system:serviceaccount:psp-ns:psp-sa -n psp-ns'
  3. Challenge

    Create the Pod Security Policy

    Use vi or a Linux editor to create the psp-policy YAML file.

    vi psp-policy.yaml

    Make sure the file is as follows.

    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
        name: psp-policy
        privileged: false  # Don't allow privileged pods!   
            rule: RunAsAny
            rule: RunAsAny
            rule: RunAsAny
            rule: RunAsAny
        - '*'

    Then create the policy.

    psp-admin create -f psp-policy.yaml
  4. Challenge

    Create a YAML File to Deploy a Pod, and Attempt to Create It

    Use an editor to create a YAML file to create a pod.

    vi pod-pause.yaml

    Edit the file as follows.

    apiVersion: v1
    kind: Pod
        name: pod-pause
        - name: pause

    Now attempt to create the pod.

    psp-user create -f pod-pause.yaml

    To explain the error, you can use can-i to see that the policy is not being used by the service account psp-sa.

    psp-user auth can-i use podsecuritypolicy/psp-policy
  5. Challenge

    Create a Rolebinding to Allow the Psp-Sa Service Account to Use the Policy and Then Re-attempt to Create the Pod

    Create a role to use the psp-policy.

    psp-admin create role psp-role --verb=use --resource=podsecuritypolicy --resource-name=psp-policy

    Create a rolebinding to bind the role to the serviceaccount.

    psp-admin create rolebinding rb-id2 --role=psp-role --serviceaccount=psp-ns:psp-sa

    Retry to create the pod as before.

    psp-user create -f pod-pause.yaml

    The pod should deploy. Check with:

    psp-user get pods
  6. Challenge

    Delete the Pod from the Previous Step and Attempt to Deploy a Privileged Pod

    Delete the pod previously deployed.

    psp-user delete po/pod-pause

    Use the editor to create a YAML file for a privileged pod.

    vi priv-pod.yaml

    The YAML file should contain the following:

    apiVersion: v1 
    kind: Pod 
        name: privileged 
        - name:  pause
            privileged: true

    Now try to create the pod.

    psp-user create -f priv-pod.yaml

    The attempt should fail.

  7. Challenge

    Attempt to Use a Deployment to Create the Unprivileged Pod

    Use an editor to create a YAML file for the deployment.

    vi psp-deploy.yaml

    The file contents should be:

    apiVersion: apps/v1 
    kind: Deployment 
        name: psp-deploy 
            app: paused 
        replicas: 1 
                app: paused 
                    app: paused 
                - name: paused

    Now attempt to create the deployment.

    psp-user create -f psp-deploy.yaml

    See if the pod deployed.

    psp-user get pods

    It should not have deployed.

    Check the events to see what happened.

    psp-user get events --sort-by='.metadata.creationTimestamp'
  8. Challenge

    Clean Up the Failed Deployment, Add the Needed Role Binding, and Re-attempt the Deployment

    Check if there are any pods running and delete as needed.

    psp-user get pods

    (delete as needed)

    psp-user delete po/[pod name]

    Check if the failed deployment exists and delete as needed.

    psp-user get deploy 

    (delete as needed)

    psp-user delete deploy/[deployment name]

    Create a role binding linking the role that allows use of the policy with the default service account.

    psp-admin create rolebinding rb-id3 --role=psp-role --serviceaccount=psp-ns:default

    Now reattempt to create the deployment as before.

    psp-user create -f psp-deploy.yaml

    Check the events to see what happened.

    psp-user get events  --sort-by='.metadata.creationTimestamp'

    Check the deployment.

    psp-user get deploy

    Check the pod.

    psp-user get pods

    Clean up as needed, and experiment with other namespaces and service accounts until this material is comfortable.

    This completes this lab.

The Cloud Content team comprises subject matter experts hyper focused on services offered by the leading cloud vendors (AWS, GCP, and Azure), as well as cloud-related technologies such as Linux and DevOps. The team is thrilled to share their knowledge to help you build modern tech solutions from the ground up, secure and optimize your environments, and so much more!

What's a lab?

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Provided environment for hands-on practice

We will provide the credentials and environment necessary for you to practice right within your browser.

Guided walkthrough

Follow along with the author’s guided walkthrough and build something new in your provided environment!

Did you know?

On average, you retain 75% more of your learning if you get time for practice.

Start learning by doing today

View Plans