Fix issues
As we now know, Kubernetes is not secure by default. It is beyond the scope of these exercises to provide a deep-dive on this topic, but detailed documentation on securing a cluster is readily available. Additional reading is recommended on configuring a security context for a pod, pod security policies, and setting capabilities for a container.
However, for the time being, we will introduce a couple of quick changes to improve our security posture. We will accomplish this by adding a few lines to our Kubernetes manifest.
1
securityContext:
2
allowPrivilegeEscalation: false
3
readOnlyRootFilesystem: true
4
runAsNonRoot: true
5
capabilities:
6
drop:
7
- all
Copied!
For your convenience, a sample file has already been created for you containing these changes. It is named azure-vote-secure.yaml and can be found in the kube-manifests/ directory of the repository for this workshop.
We will then need to apply this new file to our cluster with the following command:
1
kubectl apply -f kube-manifests/azure-vote-secure.yaml
Copied!
We should see an output similar to the following:
1
deployment.apps/azure-vote-back configured
2
service/azure-vote-back unchanged
3
deployment.apps/azure-vote-front configured
4
service/azure-vote-front unchanged
Copied!
Notice that the deployment for both the vote-back and vote-front applications show configured whereas the service for each shows as unchanged. This is expected since we have defined securityContext for these.
We will verify that our changes resolved the issue by checking our project once more. Since we have snyk-monitor running in our cluster we are actively monitoring our workloads.
Success! We've been able to identify security issues in our Kubernetes configuration, updating our manifest to include a fix, and applied these to resolve the problem.
Last modified 2d ago
Export as PDF
Copy link
Edit on GitHub