Section 9: Unblock the PROD Deployment
Let's work on fixing the identified Medium severity issues so we can unblock our Pull Request.

Step 1: Fix the issue in the Service definition YAML file

In the Project issues, Snyk calls out the issue identified, its impact, and how it can be resolved. It also highlights the line of code where the issue exists. In this case, an issue was identified in our goof-service.yaml file because the Load Balancer, as currently defined, is open to the world.
In some scenarios, such as when our load balancer being open to the world is by design because it's a client-facing web application, we can choose to ignore the issue. In this case, let's assume our Kubernetes cluster sits in a VPC, and an external Application Load Balancer is in use. We'll restrict this Kubernetes Load Balancer to the CIDR Block for our imaginary VPC.
Open goof-service.yaml with the GitHub Web Editor, and replace the contents with the following:
1
apiVersion: v1
2
kind: Service
3
metadata:
4
name: goof
5
spec:
6
type: LoadBalancer
7
loadBalancerSourceRanges:
8
- "143.231.0.0/16"
9
ports:
10
- protocol: TCP
11
port: 80
12
targetPort: 3001
13
name: "http"
14
- protocol: TCP
15
port: 9229
16
targetPort: 9229
17
name: "debug"
18
selector:
19
app: goof
20
tier: frontend
21
---
22
apiVersion: v1
23
kind: Service
24
metadata:
25
name: goof-mongo
26
spec:
27
ports:
28
- protocol: TCP
29
port: 27017
30
targetPort: 27017
31
name: "mongo"
32
selector:
33
app: goof
34
tier: backend
Copied!
When ready, propose changes by creating a new branch and opening a Pull Request. This will trigger our IaC verification workflow we set up earlier.
When checks complete, in the run details for the IaC workflow, we can appreciate that no other issues are present in the goof-service.yaml file.
Go ahead and merge the PR. Our CI workflows for the develop branch will now kick on. Once they complete, we can see that in both the GitHub Security Code Scanning results, as well as in the Snyk UI, the issue from our goof-service.yaml has vanished! Well done!

Step 2: Fix the issues in the Deployment manifest

Now, on to the goof-deployment.yaml file and its 4 blocking issues. This file actually contains two deployment definitions: one for the database, and another for the app's frontend. The four blocking issues are actually two issues, present in both deployments. Let's take a look in the Snyk UI.
The first issue states that our container is running without root user control. The second issue, in a similar vein, tells us the container runs with potentially unnecessary privileges. We can fix both of these issues by adding a securityContext in our container's spec.
This is a practical example. It's possible your application requires administrative privileges or other explicitly stated privileges. Know your application and its dependencies before arbitrarily making changes to your files, you could break your deployment if you're not careful.
Setting our SecurityContext to runAsNonRoot will require the container to run with a user with a UID other than 0, and dropping capabilities will restrict how our container interacts with the cluster. Using the GitHub Web Editor, modify the goof-deployment file's spec for both deployments.

Add Security Context to the App Container

1
spec:
2
containers:
3
- name: goof-app
4
image: goof:PROD
5
ports:
6
- containerPort: 3001
7
- containerPort: 9229
8
env:
9
- name: DOCKER
10
value: "1"
11
securityContext:
12
runAsNonRoot: true
13
capabilities:
14
drop:
15
- all
Copied!

Add Security Context to the DB Container

1
spec:
2
containers:
3
- name: goof-mongo
4
image: mongo
5
ports:
6
- containerPort: 27017
7
securityContext:
8
runAsNonRoot: true
9
capabilities:
10
drop:
11
- all
Copied!
It's possible to set securityContext for both the Pod and the Containers it runs. In this case, we're setting securityContext for the containers. Learn more in the Kubernetes Documentation.
Merge the changes into the develop branch and wait for the CI workflows to run. Like before, the issue counts will be updated in both GitHub Security Code Scanning and the Snyk UI.

Step 3: Merge our changes into PROD

Back in Section 7, our Snyk Gate blocked the Pull Request we creates from develop into PROD. Now that we've fixed the issues in our files, back in the Pull Request, we can appreciate that our tests re-ran and this time the Snyk Security Gate is pleased with the changes we made.
With this assurance, we can merge our changes into PROD. Once merged, our CI workflows will re-run for PROD. If we had a workflow to re-deploy our application, it would also run.
That's it! You reached the end of this lab! Check out the next section to recap what you accomplished.
Last modified 7d ago