Google Kubernetes Engine Security: Binary Authorization
One of the key security concerns for running Kubernetes clusters is knowing what container images are running inside each pod and being able to account for their origin. Establishing "container provenance" means having the ability to trace the source of a container to a trusted point of origin and ensuring your organization follows the desired processes during artifact (container) creation.
Some of the key concerns are:
- Safe Origin - How do you ensure that all container images running in the cluster come from an approved source?
- Consistency and Validation - How do you ensure that all desired validation steps were completed successfully for every container build and every deployment?
- Integrity - How do you ensure that containers were not modified before running after their provenance was proven?
From a security standpoint, not enforcing where images originate from presents several risks:
- A malicious actor that has compromised a container may be able to obtain sufficient cluster privileges to launch other containers from an unknown source without enforcement.
- An authorized user with the permissions to create pods may be able to accidentally or maliciously run an undesired container directly inside a cluster.
- An authorized user may accidentally or maliciously overwrite a docker image tag with a functional container that has undesired code silently added to it, and Kubernetes will pull and deploy that container as a part of a deployment automatically.
To help system operators address these concerns, Google Cloud Platform offers a capability called Binary Authorization. Binary Authorization is a GCP managed service that works closely with GKE to enforce deploy-time security controls to ensure that only trusted container images are deployed. With Binary Authorization you can whitelist container registries, require images to be signed by trusted authorities, and centrally enforce those policies. By enforcing this policy, you can gain tighter control over your container environment by ensuring only approved and/or verified images are integrated into the build-and-release process.
This lab deploys a Kubernetes Engine Cluster with the Binary Authorization feature enabled demonstrates how to whitelist approved container registries, and walks you through the process of creating and running a signed container.
This lab was created by GKE Helmsman engineers to give you a better understanding of GKE Binary Authorization. You can view this demo on Github here. We encourage any one to contribute to our assets!
이 실습의 나머지 부분과 기타 사항에 대해 알아보려면 Qwiklabs에 가입하세요.
- Google Cloud Console에 대한 임시 액세스 권한을 얻습니다.
- 초급부터 고급 수준까지 200여 개의 실습이 준비되어 있습니다.
- 자신의 학습 속도에 맞춰 학습할 수 있도록 적은 분량으로 나누어져 있습니다.
Create a Kubernetes Cluster with Binary Authorization
Update Binary Authorization Policy to add Disallow all images rule at project level and allow at cluster level
Update cluster specific policy to Disallow all images
Create a Nginx pod to verify cluster admission rule is applied for disallow all images (denies to create)
Update BA policy to denying images except from whitelisted container registries (your project container registry)
Update BA policy to modify cluster specific rule to allow only images that have been approved by attestors
Tear Down (delete cluster)