Securing Google Kubernetes Engine (GKE) Deployment with Google Container Registry (GCR) - Best Practices

Secure GKE Deployment with GCR: Minimizing Development Time

Question

Your application services run in Google Kubernetes Engine (GKE)

You want to make sure that only images from your centrally-managed Google Container Registry (GCR) image registry in the altostrat-images project can be deployed to the cluster while minimizing development time.

What should you do?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

D.

The correct answer is B. Use a Binary Authorization policy that includes the whitelist name pattern gcr.io/altostrat-images/.

Google Kubernetes Engine (GKE) is a managed Kubernetes service provided by Google Cloud Platform (GCP). GKE allows users to deploy, manage, and scale containerized applications on a Kubernetes cluster. GCP provides Google Container Registry (GCR), which is a private Docker registry that enables users to store, manage, and secure their Docker container images. To deploy only images from the centrally-managed GCR image registry in the altostrat-images project, while minimizing development time, we need to enforce this requirement using a Binary Authorization policy.

Binary Authorization is a GCP service that enforces deploy-time checks on container images. With Binary Authorization, you can set policies that restrict the deployment of container images based on their properties, such as the image name, the registry where the image is stored, or the contents of the image. Binary Authorization policies are enforced using attestations, which are digital signatures that verify the origin and integrity of the container image.

To enforce the requirement that only images from the altostrat-images project can be deployed to the GKE cluster, we can create a Binary Authorization policy that includes a whitelist name pattern for the GCR registry. The whitelist name pattern will ensure that only images from the specified registry can be deployed to the cluster, while minimizing development time by allowing developers to push images to the same GCR registry that they use for development.

Option A, creating a custom builder for Cloud Build that will only push images to gcr.io/altostrat-images, is not the best solution because it does not enforce the policy at deploy-time. Developers could still push images to other GCR registries, and the images could be deployed to the cluster if the policy is not enforced.

Option C, adding logic to the deployment pipeline to check that all manifests contain only images from gcr.io/altostrat-images, is also not the best solution because it does not enforce the policy at deploy-time. Developers could still push images to other GCR registries, and the images could be deployed to the cluster if the policy is not enforced.

Option D, adding a tag to each image in gcr.io/altostrat-images and checking that this tag is present when the image is deployed, is not the best solution because it does not enforce the policy at deploy-time. Developers could still push images to other GCR registries, and the images could be deployed to the cluster if the policy is not enforced. Additionally, relying on tags to enforce policies can be error-prone and can lead to security vulnerabilities.