As demonstrated in the previous section, the Dev CD workflow created our environment, deployed the application, tested it, and attested application images. It then automatically initiated a pull request to merge the code into the prod branch.
We’ve entered the release gating phase, where we require manual verification to determine whether the code is ready for merging into the prod branch.
Since we know the pull request has been created, let’s proceed to inspect and approve it. To do so, go to https://github.com//mdo-environments/pulls, where you will find the pull request. Click on the pull request, and you will encounter the following:
Figure 13.15 – Pull request
We see that the pull request is ready to merge. Click on Merge pull request, and you will see that the changes will reflect on the prod branch.
If you go to https://github.com//mdo-environments/actions, you’ll find that the Prod CD workflow has been triggered. When you click on the workflow, you will see a workflow run like the following:
Figure 13.16 – Prod CD workflow
When we merged the pull request, it automatically triggered the Prod CD workflow as it would react to any new changes in the prod branch. The workflow did its job by building the Prod environment, deploying our application, and testing it. Note that binary authorization is enabled for this cluster.
To confirm that binary authorization is functioning correctly, let’s perform some checks to ensure unattested images cannot be deployed.
First, let’s establish a connection to the prod cluster using the following command:
$ gcloud container clusters get-credentials \ mdo-cluster-prod –zone us-central1-a –project ${PROJECT_ID}
Let’s attempt to deploy a pod to your cluster using an nginx image. Please use the following command:
$ kubectl run nginx –image=nginx
Error from server (VIOLATES_POLICY): admission webhook “imagepolicywebhook.image-policy. k8s.io” denied the request: Image nginx denied by Binary Authorization default admission rule. Image nginx denied by attestor projects//attestors/quality-assurance-attestor: Expected digest with sha256 scheme, but got tag or malformed digest
Now, as expected, the deployment failed, but there’s something else to note if you examine the reason. The failure happened because we specified a tag instead of a sha256 digest. Let’s attempt to deploy the image again, but this time, with a digest.
To do so, let’s retrieve the image digest and set it as a variable called DIGEST using the following command:
$ DIGEST=$(docker pull nginx | grep Digest | awk {‘print $2’})
Now, let’s redeploy the image using the digest with the following command:
$ kubectl run nginx –image=nginx@$DIGEST
Error from server (VIOLATES_POLICY): admission webhook “imagepolicywebhook.image-policy.k8s.io” denied the request: Image nginx@sha256:6926dd8… denied by Binary Authorization default admission rule. Image nginx@sha256:6926dd8… denied by attestor projects//attestors/quality-assurance-attestor: No attestations found that were valid and signed by a key trusted by the attestor
This time, the deployment was denied for a valid reason, confirming that binary authorization functions correctly. This ensures the security of your Kubernetes cluster, preventing the deployment of unattested images and giving you complete control over your environment. With this in place, any issues that arise won’t stem from deploying untested or vulnerable images.
We’ve covered a lot of ground in integrating security and QA into our CI/CD pipelines. Now, let’s explore some best practices for securing modern DevOps pipelines.
