remove all trailing whitespace

Author: erikdw

001-Lab-Setup/README.md

@@ -22,24 +22,24 @@ Note: You may need to refresh the page a few times before seeing your Kubernetes
 In the navigation on the left side of the console, click `Kubernetes Engine`. Here you will find the details about the cluster and a GUI for accessing and administering workloads and services.
 
 ## Task 3: Launch Cloud Shell
-There is a button titled `Activate Google Cloud Shell` located in the top-bar navigation of the console. When clicked, a terminal will appear in the lower half of the console. This gives you direct command-line access to your Kubernetes cluster. 
+There is a button titled `Activate Google Cloud Shell` located in the top-bar navigation of the console. When clicked, a terminal will appear in the lower half of the console. This gives you direct command-line access to your Kubernetes cluster.
 
 Cloud shell comes packaged with a beta feature called `code editor` which gives you a minimal IDE for viewing and editing files. This will be used throughout the remainder of the labs. The link is found in the upper-right hand corner of the terminal.
 
 ## Task 4: Clone the Git Repository
 In your home directory, we are going to pull in the documentation and source code used for the course labs. We can do this by running the following command:
 ```
-git clone https://github.com/ManicodeSecurity/Defending-DevOps/ 
+git clone https://github.com/ManicodeSecurity/Defending-DevOps/
 ```
 
 ## Task 5: Connect to your Kubernetes Cluster
-Most of the tools necessary to complete the labs come pre-installed in Google Cloud Shell including `kubectl` which is used extensively to interact with your cluster. Ensure your cluster is operational by running the following commands. 
+Most of the tools necessary to complete the labs come pre-installed in Google Cloud Shell including `kubectl` which is used extensively to interact with your cluster. Ensure your cluster is operational by running the following commands.
 
 First, we need to use connect to the cluster using Cloud Shell. In the navigation on the left, click `Kubernetes Engine -> Cluster` then click the `Connect` button next to your cluster:
 
 ![Cluster Connect](../images/gke-connect.png)
 
-You will then be presented with options to connect to the cluster. Click `Run in Cloud Shell`. This will open Google Cloud Shell in the same browser tab. It will also paste a command into the terminal. All you need to do now is hit enter to run the command. 
+You will then be presented with options to connect to the cluster. Click `Run in Cloud Shell`. This will open Google Cloud Shell in the same browser tab. It will also paste a command into the terminal. All you need to do now is hit enter to run the command.
 
 The command you are running will look like this:
 ```

002-Containerizing-An-Application/README.md

@@ -8,7 +8,7 @@ The source code for the application located in the `src/link-unshorten` director
 ### Task 1: Browse the Application
 Open up the files in `src/link-unshorten` in your favorite IDE or the Cloud Shell editor and familiarize yourself with the application.
 
-### Task 2: Build the Docker Image 
+### Task 2: Build the Docker Image
 In the `src/link-unshorten` directory run the following command (substituting <yourname> with your own identifier) to build the image on the Cloud Shell VM:
 ```
 docker build -t <yourname>/link-unshorten:0.1 .
@@ -92,7 +92,7 @@ Hint 3: Yes, the answer is commented in the source code
 Hint 4: You will need to run `docker stop` on the first running container before running another one with the same port
 
 ### Bonus 3: Inspect the Docker image
-[dive](https://github.com/wagoodman/dive) is an OSS project that helps with visualization and optimization of images. 
+[dive](https://github.com/wagoodman/dive) is an OSS project that helps with visualization and optimization of images.
 
 Install `dive` in Cloud Shell and inspect the unshorten image that was created.
 

003-Cluster-Setup/README.md

@@ -16,7 +16,7 @@ echo "Default Namespace Switched:" $(kubectl get sa default -o jsonpath='{.metad
 1. `kubectl` is the command line utility that we will use to interact with our Kubernetes cluster. The first task is to view the Pods that are running on our cluster with an out-of-the-box installation. Run the following command in you terminal:
 ```
 kubectl get pods
-``` 
+```
 
 2. As you can see no pods are running. This is because we are dropped into the `default` namespace and the `default` namespace has nothing deployed to it. Try running the same command with the following argument. This will list the pods used by the Kubernetes system itself:
 ```
@@ -86,7 +86,7 @@ exit
 ### Task 3: Exposing your Pod to the World
 There are a variety of ways to make our Pod accessible to the outside world. A Service with the type `LoadBalancer` will be used to give our Pod a stable existence and an IP we can reach from our web browser.
 
-The `LoadBalancer` type spins up a load balancer in GCP automatically. 
+The `LoadBalancer` type spins up a load balancer in GCP automatically.
 
 1. To expose the application we create a Service with the type of LoadBalancer:
 ```
@@ -106,7 +106,7 @@ http://<EXTERNAL-IP>:8080/api/check?url=bit.ly/test
 4. This is no way to manage a real Kubernetes cluster. Tear down your app using the following commands:
 ```
 kubectl delete pod link-unshorten && kubectl delete svc link-unshorten
-``` 
+```
 
 ### Task 4: "Codifying" Your Deployment
 Running ad hoc commands in a terminal are no way to maintain a proper DevOps infrastructure. Kubernetes is built with "Infrastructure as Code" in mind by using manifests. Manifests can be written in JSON and YAML. We will be using YAML for all labs.
@@ -124,7 +124,7 @@ kubectl create -f link-unshorten-service.yaml
 kubectl get pods
 ```
 
-4. Under the hood we can see the new ReplicaSet that was created. Remember, a Deployment actually creates a ReplicaSet. Deployments provide the same replication functions via ReplicaSets and also the ability to rollout changes and roll them back if necessary. 
+4. Under the hood we can see the new ReplicaSet that was created. Remember, a Deployment actually creates a ReplicaSet. Deployments provide the same replication functions via ReplicaSets and also the ability to rollout changes and roll them back if necessary.
 ```
 kubectl get replicaset
 ```
@@ -137,14 +137,14 @@ kubectl describe svc link-unshorten-service
 6. Similar to how we interacted with our application earlier, we use the IP from the above output and paste it into our browser.
 ```
 http://<EXTERNAL-IP>/api/check?url=bit.ly/test
-``` 
+```
 
 ### Task 5: Scale
 
 1. We will first increase the number of pods in our Deployment using `kubectl scale`. Note - This will not reflect what is defined in the manifest. These values will be out of sync.
 
 ```
-kubectl scale deployment/link-unshorten --replicas=4 
+kubectl scale deployment/link-unshorten --replicas=4
 kubectl get pods
 # 4 pods should be running
 ```
@@ -169,7 +169,7 @@ kubectl delete hpa <HPA_NAME>
 5. Relaunch our Deployment from the manifest file:
 ```
 kubectl create -f link-unshorten-deployment.yaml
-kubectl get pods 
+kubectl get pods
 # two pods should be running
 ```
 
@@ -181,7 +181,7 @@ kubectl replace -f link-unshorten-deployment.yaml
 
 7. Inspect the Pods scaling. Note that others will be terminating at the same time:
  ```
- kubectl get pods 
+ kubectl get pods
  ```
 
 ### Multi-Container Pods
@@ -207,7 +207,7 @@ exit
 ```
 
 ### Bonus
- A critical RCE vulnerability was just reported through a bug bounty and was fixed late into the night. Roll out a new version of the app (0.2) in your cluster to patch the vulnerability on each of your three running pods. No downtime allowed! Show the deployment history using `kubectl rollout history` 
+ A critical RCE vulnerability was just reported through a bug bounty and was fixed late into the night. Roll out a new version of the app (0.2) in your cluster to patch the vulnerability on each of your three running pods. No downtime allowed! Show the deployment history using `kubectl rollout history`
 
 ### Bonus 2
 The new version you just rolled out contains a critical bug! Quickly rollback the deployment to 0.1 (Yes, 0.1 is the vulnerable version, but this is just for practice!)
@@ -221,6 +221,6 @@ echo "Default Namespace Switched:" $(kubectl get sa default -o jsonpath='{.metad
 ```
 
 ### Discussion Questions
-1. What would be a good piece of your application or infrastructure to start breaking up into Pods within Kubernetes? 
+1. What would be a good piece of your application or infrastructure to start breaking up into Pods within Kubernetes?
 
-2. What security challenges does administering a Kubernetes cluster using a tool like kubectl present? 
+2. What security challenges does administering a Kubernetes cluster using a tool like kubectl present?

003-Cluster-Setup/manifests/link-unshorten-deployment.yaml

@@ -3,7 +3,7 @@ kind: Deployment
 metadata:
   # A Deployment named link-unshorten is created using the metadata: name field
   name: link-unshorten
-  # We give the deployment a label 
+  # We give the deployment a label
   labels:
     app: unshorten-api
 spec:
@@ -13,7 +13,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         # We label all Pods in this deployment as app: unshorten-api

004-Cluster-Authentication/README.md

@@ -13,7 +13,7 @@ Kubernetes Engine Admin
 Editor
 
 User 2: <your-intern-email>@manicode.us
-Roles: 
+Roles:
 Minimal GKE Role
 Browser
 ```
@@ -26,11 +26,11 @@ container.clusters.getCredentials
 ```
 
 ### Task 1: Launch Your Infrastructure
-First, we will spin up our application in both a `development` and `production` namespace. 
+First, we will spin up our application in both a `development` and `production` namespace.
 
 Note: You should be logged in to Cloud Shell using the admin account provided at the beginning of class to run the following commands, NOT `<your-intern-email>@manicode.us`.
 
-We need to retrieve the credentials of our running cluster using the following `gcloud` command. This command updates our kubeconfig in Cloud Shell file with appropriate credentials and endpoint information to point kubectl at a specific cluster in Google Kubernetes Engine. 
+We need to retrieve the credentials of our running cluster using the following `gcloud` command. This command updates our kubeconfig in Cloud Shell file with appropriate credentials and endpoint information to point kubectl at a specific cluster in Google Kubernetes Engine.
 
 ```
 # Use gcloud get-credentials to retrieve the cert
@@ -65,11 +65,11 @@ kubectl get pods --all-namespaces
 Take note of this process. Our user has full administrative access to our cluster due to being provisioned with the `Kubernetes Engine Admin` role. We will now see how RBAC helps give us granular access control at the object-level within our cluster.
 
 ### Task 2: Authenticate as a Restricted User
-We will now log in using a separate user who has very locked down access to the entire project. In an incognito window browse to `cloud.google.com` and authenticate with the user `<your-intern-email>@manicode.us` and the same password that was provided to you for the admin user. 
+We will now log in using a separate user who has very locked down access to the entire project. In an incognito window browse to `cloud.google.com` and authenticate with the user `<your-intern-email>@manicode.us` and the same password that was provided to you for the admin user.
 
-Note: *Using the same password for multiple accounts is bad. Don't do this at home.* 
+Note: *Using the same password for multiple accounts is bad. Don't do this at home.*
 
-Now open up Cloud Shell and use the following `gcloud get-credentials` command to retrieve the credentials for your user so we can start interacting with the cluster. This is the same cluster you just launched the `production` and `development` infrastructure in. 
+Now open up Cloud Shell and use the following `gcloud get-credentials` command to retrieve the credentials for your user so we can start interacting with the cluster. This is the same cluster you just launched the `production` and `development` infrastructure in.
 
 ```
 # Authenticate to the cluster
@@ -80,7 +80,7 @@ Now, attempt to run some `kubectl` queries on the cluster.
 ```
 kubectl get pods --namespace=production
 kubectl get pods --namespace=development
-kubectl get secrets 
+kubectl get secrets
 kubectl run link-unshorten --image=jmbmxer/link-unshorten:0.1 --port=8080
 ```
 These should all fail with a `Forbidden` error. While <your-intern-email>@manicode.us does technically have an account on the cluster, RBAC is stopping it from accessing any of the objects.
@@ -93,7 +93,7 @@ kubectl auth can-i list secrets --namespace default
 ```
 
 ### Task 3: Add Yourself as `cluster-admin`
-By default, User 1 will not be able to create the `roles` or `rolebindings` needed to begin building our RBAC policies. We need to ensure User 1 (our Administrator) has the appropriate access to the cluster by granting the user `cluster-admin` rights. 
+By default, User 1 will not be able to create the `roles` or `rolebindings` needed to begin building our RBAC policies. We need to ensure User 1 (our Administrator) has the appropriate access to the cluster by granting the user `cluster-admin` rights.
 
 `cluster-admin` is one of several Default User-facing roles included with every Kubernetes installation. They should be used with caution as many of these roles grant excessive privileges and are often abused for a quick fix.
 
@@ -124,10 +124,10 @@ kubectl auth can-i create roles --as=root --as-group=system:authenticated --as-g
 yes
 ```
 
-### Task 4: Create RBAC Rules 
+### Task 4: Create RBAC Rules
 Our user `<your-intern-email>@manicode.us` is a restricted user so we only want to grant access to read pods in the `development` namespace and nothing more. We will use RBAC to enforce a policy
 
-Now, open the file `user-role-binding.yaml` in the `manifests/role` directory and replace <your-intern-email> with the one provided to you. It will be the same as your admin account but with the word `intern` at the end (eg. `manicode0003intern@manicode.us`). 
+Now, open the file `user-role-binding.yaml` in the `manifests/role` directory and replace <your-intern-email> with the one provided to you. It will be the same as your admin account but with the word `intern` at the end (eg. `manicode0003intern@manicode.us`).
 ```
 # In the manifests/role directory
 kubectl create -f .

004-Cluster-Authentication/manifests/development/link-unshorten-deployment.yaml

@@ -4,7 +4,7 @@ metadata:
   # A Deployment named link-unshorten is created using the metadata: name field
   name: link-unshorten
   namespace: development
-  # We give the deployment a label 
+  # We give the deployment a label
   labels:
     app: unshorten-api
 spec:
@@ -14,7 +14,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         # We label all Pods in this deployment as app: unshorten-api

004-Cluster-Authentication/manifests/production/link-unshorten-deployment.yaml

@@ -4,7 +4,7 @@ metadata:
   # A Deployment named link-unshorten is created using the metadata: name field
   name: link-unshorten
   namespace: production
-  # We give the deployment a label 
+  # We give the deployment a label
   labels:
     app: unshorten-api
 spec:
@@ -14,7 +14,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         # We label all Pods in this deployment as app: unshorten-api

007-Network-Policies/README.md

@@ -14,7 +14,7 @@ echo "Default Namespace Switched:" $(kubectl get sa default -o jsonpath='{.metad
 ```
 
 ### Task 2: Create our Network Policy
-Go to the `manifests/network-policies` directory and inspect the Network policy named `hello-unshorten.yaml`. This policy simply selects Pods with label `app=unshorten-api` and specifies an ingress policy to allow traffic only from Pods with the label `app=unshorten-fe`. We only want to allow traffic from pods that are acting as frontends to our API. 
+Go to the `manifests/network-policies` directory and inspect the Network policy named `hello-unshorten.yaml`. This policy simply selects Pods with label `app=unshorten-api` and specifies an ingress policy to allow traffic only from Pods with the label `app=unshorten-fe`. We only want to allow traffic from pods that are acting as frontends to our API.
 
 In the `manifests/network-policies` directory run:
 ```

007-Network-Policies/manifests/api/link-unshorten-deployment.yaml

@@ -9,7 +9,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         app: unshorten-api

008-Istio/README.md

@@ -24,7 +24,7 @@ gcloud beta container clusters update $(gcloud container clusters list --format
 
 (!)Ensure all cluster operations are labeled `DONE` before continuing(!)
 ```
-gcloud beta container operations list 
+gcloud beta container operations list
 ```
 
 ### Task 2: Verify our Istio Installation
@@ -80,7 +80,7 @@ Lets build some rules to explicit allow outbound egress traffic to only bit.ly a
 kubectl create -f .
 ```
 
-Once the rules are created, try to visit the API again and you should be able to successfully unshorten links to `bit.ly` domains only. 
+Once the rules are created, try to visit the API again and you should be able to successfully unshorten links to `bit.ly` domains only.
 
 ```
 http://35.197.37.188/api/check?url=https://bit.ly/hi

008-Istio/manifests/api/link-unshorten-deployment.yaml

@@ -3,7 +3,7 @@ kind: Deployment
 metadata:
   # A Deployment named link-unshorten is created using the metadata: name field
   name: link-unshorten
-  # We give the deployment a label 
+  # We give the deployment a label
   labels:
     app: unshorten-api
 spec:
@@ -13,7 +13,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         # We label all Pods in this deployment as app: unshorten-api

009-Secrets/README.md

@@ -148,13 +148,13 @@ curl \
     http://127.0.0.1:8200/v1/secret/mysql
 ```
 
-### Task 4: Using Vault to Store and inject our MySQL Password 
+### Task 4: Using Vault to Store and inject our MySQL Password
 
 We can now call the Vault API to inject our secret into our `kubectl create` command on the fly as follows.
 
 First, delete `mysql-secrets` from our cluster:
 ```
-kubectl delete secret mysql-secrets 
+kubectl delete secret mysql-secrets
 ```
 
 navigate to `manifests/secrets` and run:

009-Secrets/manifests/api/link-unshorten-deployment.yaml

@@ -9,7 +9,7 @@ spec:
   selector:
     matchLabels:
       app: unshorten-api
-  template: 
+  template:
     metadata:
       labels:
         app: unshorten-api

009-Secrets/manifests/vault/vault-statefulset.yaml

@@ -1,5 +1,5 @@
 apiVersion: apps/v1beta1
-# StatefulSets are intended to be used with stateful applications and distributed systems. 
+# StatefulSets are intended to be used with stateful applications and distributed systems.
 kind: StatefulSet
 metadata:
   name: vault

010-Security-Pipeline/README.md

@@ -1,5 +1,5 @@
 # Security Pipeline and Automation
-This lab will spin up Jenkins in our cluster along with a private Docker image repository. Jenkins will also handle zero-downtime deploys of the unshorten API upon a successful build. The humble beginnings of a self-contained DevSecOps pipeline. 
+This lab will spin up Jenkins in our cluster along with a private Docker image repository. Jenkins will also handle zero-downtime deploys of the unshorten API upon a successful build. The humble beginnings of a self-contained DevSecOps pipeline.
 
 ### Create the `lab010` Namespace and Use as Default
 
@@ -39,7 +39,7 @@ We need a location to store our versioned Docker images within our Kubernetes cl
 kubectl create -f .
 ```
 
-2. Once all of the Pods and Services are up and healthy, grab the URL for our freshly created registry and visit it in your browser. 
+2. Once all of the Pods and Services are up and healthy, grab the URL for our freshly created registry and visit it in your browser.
 
 Note: The registry runs on port `8080`.
 ```
@@ -83,7 +83,7 @@ kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &
 https://github.com/ManicodeSecurity/unshorten-jenkins-demo
 ```
 
-5. Inspect the `Jenkinsfile` in the repo. It has the humble beginnings of an AppSec and DevSecOps pipeline. Each stage is meant to apply automation to the process where issues result in failed builds. 
+5. Inspect the `Jenkinsfile` in the repo. It has the humble beginnings of an AppSec and DevSecOps pipeline. Each stage is meant to apply automation to the process where issues result in failed builds.
 
 ### Task 4: Trigger a Build
 Most pipeline setups will trigger builds on a git commit or through some other automated manner. To simulate this, we will tell Jenkins to trigger a build manually: