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.
securityContext:allowPrivilegeEscalation: falsereadOnlyRootFilesystem: truerunAsNonRoot: truecapabilities:drop:- all
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:
kubectl apply -f kube-manifests/azure-vote-secure.yaml
We should see an output similar to the following:
deployment.apps/azure-vote-back configuredservice/azure-vote-back unchangeddeployment.apps/azure-vote-front configuredservice/azure-vote-front unchanged
Notice that the
deployment for both the
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.