menu
arrow_back

Google Kubernetes Engine Security: Binary Authorization

Google Kubernetes Engine Security: Binary Authorization

1時間 30分 クレジット: 7

GKE-Engine.png

GSP479

Google Cloud Self-Paced Labs

Overview

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 を超えるラボが用意されています。
  • ご自分のペースで学習できるように詳細に分割されています。
参加してこのラボを開始
スコア

—/100

Create a Kubernetes Cluster with Binary Authorization

ステップを実行

/ 20

Update Binary Authorization Policy to add Disallow all images rule at project level and allow at cluster level

ステップを実行

/ 10

Update cluster specific policy to Disallow all images

ステップを実行

/ 10

Create a Nginx pod to verify cluster admission rule is applied for disallow all images (denies to create)

ステップを実行

/ 10

Update BA policy to denying images except from whitelisted container registries (your project container registry)

ステップを実行

/ 10

Update BA policy to modify cluster specific rule to allow only images that have been approved by attestors

ステップを実行

/ 20

Tear Down (delete cluster)

ステップを実行

/ 20