Binary authorization is a deploy-time security mechanism that ensures that only trusted binary files are deployed within your environments. In the context of containers and Kubernetes, binary authorization uses signature validation and ensures that only container images signed by a trusted authority are deployed within your Kubernetes cluster.
Using binary authorization gives you tighter control over what is deployed in your cluster. It ensures that only tested containers and those approved and verified by a particular authority (such as security tooling or personnel) are present in your cluster.
Binary authorization works by enforcing rules within your cluster via an admission controller. This means you can create rulesets only to allow images signed by an attestation authority to be deployed in your cluster. Your quality assurance (QA) team can be a good attestor in a practical scenario. You can also embed the attestation within your CI/CD pipelines. The attestation means your images have been tested and scanned for vulnerabilities and have passed a minimum standard to be ready to be deployed to the cluster.
GCP provides binary authorization embedded within GKE, based on the open source project Kritis (https://github.com/grafeas/kritis). It uses a public key infrastructure (PKI) to attest and verify images—so your images are signed by an attestor authority using the private key, and Kubernetes verifies the images by using the public key. The following diagram explains this beautifully:
Figure 13.12 – Binary authorization process
In the hands-on exercise, we will set up binary authorization and a PKI using Google Cloud KMS. Next, we will create a QA attestor and an attestation policy for all binary auth-enabled GKE clusters, ensuring that only attested images can be deployed. Since our application is now tested, the next step is to attest the tested images. So, let’s proceed to set up binary authorization within our Dev CD workflow in the next section.
