Your company has an application running as a Deployment in a Google Kubernetes Engine (GKE) cluster.
You have separate clusters for development, staging, and production.
You have discovered that the team is able to deploy a Docker image to the production cluster without first testing the deployment in development and then staging.
You want to allow the team to have autonomy but want to prevent this from happening.
You want a Google Cloud solution that can be implemented quickly with minimal effort.
What should you do?
Click on the arrows to vote for the correct answer
A. B. C. D.C.
The scenario presented involves an organization that has an application running as a deployment in a Google Kubernetes Engine (GKE) cluster. The organization has multiple clusters for development, staging, and production. However, the organization has discovered that the team is able to deploy a Docker image to the production cluster without first testing it in development and staging clusters. The organization wants to allow the team to have autonomy while also preventing this from happening. The organization is seeking a Google Cloud solution that can be implemented quickly with minimal effort.
Option A suggests configuring a Kubernetes lifecycle hook to prevent the container from starting if it is not approved for usage in the given environment. Kubernetes lifecycle hooks are used to trigger containers in response to specific events in the lifecycle of a pod, such as before the container is started or after the container is terminated. This option would involve creating a custom script that would be executed before a container is started in a particular environment. The script would check whether the container has been approved for usage in the given environment. If the container has not been approved, the script would prevent the container from starting. While this option would prevent unapproved containers from starting, it would require creating and maintaining custom scripts for each environment, which may not be a quick or scalable solution.
Option B suggests implementing a corporate policy to prevent teams from deploying Docker images to an environment unless the Docker image was tested in an earlier environment. This option involves creating a policy that requires team members to test the Docker image in earlier environments before deploying it to a later environment. This policy could be communicated to team members through training or documentation, and could be enforced through regular audits or reviews. While this option may be a simple solution to implement, it relies on the diligence of team members to follow the policy, which may not always be the case.
Option C suggests configuring binary authorization policies for the development, staging, and production clusters and creating attestations as part of the continuous integration pipeline. Binary authorization policies are used to enforce a set of conditions that must be met before a container image can be deployed to a Kubernetes cluster. Attestations are used to record the set of conditions that were met when a container image was built. This option would involve configuring binary authorization policies for each environment, creating attestations for each container image that is built, and integrating attestations into the continuous integration pipeline. While this option may require more effort to set up initially, it provides a more robust solution that can be scaled to multiple environments and ensures that only approved containers can be deployed.
Option D suggests creating a Kubernetes admissions controller to prevent the container from starting if it is not approved for usage in the given environment. Admissions controllers are used to intercept requests to the Kubernetes API server and make decisions about whether to allow the requests to proceed or not. This option would involve creating a custom admissions controller that would be responsible for checking whether a container has been approved for usage in the given environment before allowing it to start. While this option may provide a more flexible solution than option A, it would require creating and maintaining a custom admissions controller, which may not be a quick or scalable solution.
In summary, while all the options provided could potentially address the problem, option C - configuring binary authorization policies for the development, staging, and production clusters and creating attestations as part of the continuous integration pipeline - would provide the most robust solution that can be scaled to multiple environments and ensure that only approved containers can be deployed.