Secure Workloads in Google Kubernetes Engine: Challenge Lab[GSP 335]

This lab is recommended for students who have completed the labs in the Secure Workloads in Google Kubernetes Engine quest. Are you ready for the challenge?

Topics tested:

• Enable TLS access using nginx-ingress and cert-manager.io
• Secure traffic with a network policy
• Enable Binary Authorization to ensure only approved images are deployed
• Ensure that pods do not allow escalations to root

Task 0: Download the necessary files

1. Open Cloud Shell and run the following to collect all the files made available to you:

gsutil cp gs://spls/gsp335/gsp335.zip .
unzip gsp335.zip

Task 1: Setup Cluster

To create a cluster for your demo, use the following values to ensure you have enough resources:

• zone: us-central1-c
• machine-type: standard-4
• nodes: 2
• Enable network policy

gcloud container clusters create kraken-cluster \
   --zone us-central1-c \
   --machine-type n1-standard-4 \
   --num-nodes 2 \
   --enable-network-policy

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Task 2: Setup WordPress

If you have not setup WordPress using Cloud SQL before, here are some general steps for you here:

Setup the Cloud SQL database and database username and password

2. Create a Cloud SQL instance in us-central1, using the default values.

gcloud sql instances create kraken-cloud-sql --region us-central1

2. Create a Cloud SQL database for WordPress.

1.In the Cloud Console, click on Navigation Menu > SQL.

2.Once the Cloud SQL instance is ready, select the Databases tab on the left panel.

3.Click CREATE DATABASE.

4.Enter wordpress as the database name.

4.Click Create.

2. Create a user using the following values:

1. In the Cloud SQL page, select the Users tab on the left panel.
2. Click *ADD USER ACCOUNT.
3. Enter wordpress as the User name.
4. Enter a password that you can remember.
5. Select Allow any host (%) for the name of Host.
6. Click Add.

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Create a service account for access to your WordPress database from your WordPress instances

5. Create the service account.

gcloud iam service-accounts create kraken-wordpress-sa
gcloud projects add-iam-policy-binding $DEVSHELL_PROJECT_ID \
   --member="serviceAccount:kraken-wordpress-sa@$DEVSHELL_PROJECT_ID.iam.gserviceaccount.com" \
   --role="roles/cloudsql.client"
gcloud iam service-accounts keys create key.json \
--iam-account=kraken-wordpress-sa@$DEVSHELL_PROJECT_ID.iam.gserviceaccount.com

Use this as a template:Bind the service account to your project, give the role roles/cloudsql.client.

5. Save the service account credentials in a json file.

6. Save the service account json file as a secret in your Kubernetes cluster.

kubectl create secret generic cloudsql-instance-credentials --from-file key.json

9. Save the WordPress database username and password you used in step #4 as secrets in your Kubernetes cluster.

Use this as a template:

kubectl create secret generic cloudsql-db-credentials \
    --from-literal username=wordpress \
    --from-literal password=''

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Create the WordPress deployment and service

10. Use kubectl create -f volume.yaml to create a persistent volume for your WordPress application.

11. Open wordpress.yaml and replace INSTANCE_CONNECTION_NAME with the instance name of your Cloud SQL database (the format is project:region:databasename).

12. Use kubectl apply -f wordpress.yaml to create the WordPress environment.

goto editor and reolace isntance name with sql instance name 
save 

kubectl apply -f wordpress.yaml

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Task 3: Setup Ingress with TLS

Set up nginx-ingress environment

13. Make sure you add and update the stable repo for helm.

14. Install stable nginx-ingress (call it nginx-ingress).

helm version

helm repo add stable https://charts.helm.sh/stable
helm repo update

helm install nginx-ingress stable/nginx-ingress --set rbac.create=true

Set up your DNS record

15. Check the service nginx-ingress-controller as an external IP address before continuing (kubectl get svc) to the next step.

kubectl get service

15. Run the command . add_ip.sh. You should see record added. You now have a DNS record added of the format YOUR_LAB_USERNAME.labdns.xyz which points to your ingress cluster (the script will output your DNS name).

. add_ip.sh  

*COPY THE USER NAME

Set up cert-manager.io

17. Install cert-manager.io (make sure you use the right version - v0.16.0 works well with this lab).

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml

17. kubectl create clusterrolebinding cluster-admin-binding \
       --clusterrole=cluster-admin \
       --user=$(gcloud config get-value core/account)

18. Edit issuer.yaml and set the email address to the email address of your wordpress service account.

19. goto editor and edit issuer.yaml to include lab email address
    
    kubectl apply -f issuer.yaml

20. Use kubectl apply -f issuer.yaml to setup the lets encrypt prod issuer.

Configure nginx-ingress to use an encrypted certificate for your site

20. Edit ingress.yaml and set the dns and domain name to your YOUR_LAB_USERNAME.labdns.xyz. Don't forget to remove any _ characters from your username when using it as the dns.

21. Use kubectl apply -f ingress.yaml.

goto editor and edit ingress.yaml to include dns address received as output from . add_ip.sh

kubectl apply -f ingress.yaml

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Task 4: Set up Network Policy

22. Show your colleagues how to restrict the network traffic using the provided network-policy.yaml file. It's not complete; you will need to add the configuration to allow ingress traffic from the world into nginx-ingress, but you can solve that easily.

goto editor and in network-policy.yaml add to end

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-world-to-nginx-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx-ingress
  policyTypes:
  - Ingress
  ingress:
  - {}

kubectl apply -f network-policy.yaml

If you don't get a green check mark, click on the Score fly-out on the top right and click Check my progress on the relevant step. A hint pop up opens to give you advice.

Task 5: Setup Binary Authorization

23. Show your colleagues how to configure Binary Authorization to only allow the following images in your cluster:

• docker.io/library/wordpress:latest
• us.gcr.io/k8s-artifacts-prod/ingress-nginx/*
• gcr.io/cloudsql-docker/*
• quay.io/jetstack/*

Configure Binary Authorization Policy

1. In the Cloud Console, navigate to Security > Binary Authorization.
2. Enable the Binary Authorization API.
3. On the Binary Authorization page, click on CONFIGURE POLICY.
4. Select Disallow all images for the Default rule.
5. Scroll down to Images exempt from this policy, click ADD IMAGE PATH.
6. Paste docker.io/library/wordpress:latest to the textbox, and click DONE.
7. Repeat the above two steps to add the following image paths:
   • docker.io/library/wordpress:latest
   • us.gcr.io/k8s-artifacts-prod/ingress-nginx/*
   • gcr.io/cloudsql-docker/*
   • quay.io/jetstack/*
8. Click SAVE POLICY.

Enable Binary Authorization in Google Kubernetes Engine

1. Navigate to Kubernetes Engine > Clusters.
2. Click your cluster name to view its detail page.
3. Click on the pencil icon for Binary authorization under the Security section.

4. Check Enable Binary Authorization in the dialog.
5. Click SAVE CHANGES.

Task 6: Setup Pod Security Policy

24. Some Pod Security Policy demo files have been provided for you to use in your demo. They will forbid the use of the root user and prevent the mounting of the host filesystem within a container.

Remember to check the restrictions using a service account that has the role roles/container.developer as this will simulate a typical developer.

edit psp-restrictive.yaml 

line 2 change extensions/v1beta1 to policy/v1beta1

kubectl apply -f psp-restrictive.yaml

kubectl apply -f psp-role.yaml

kubectl apply -f psp-use.yaml

Watch my youtube vedio.