Binary Authorization による Cloud Run のデプロイ保護
Google Cloud Japan Team
※この投稿は米国時間 2022 年 10 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
Binary Authorization による Cloud Run のデプロイ保護
コンテナ上でアプリケーションとワークロードを実行することは、多くの組織、特にクラウド上で実行している組織にとって標準になりつつあります。これは、アプリケーションをマイクロサービスとして設計することの利点によるものです。こうした利点には、スケーラビリティの向上、より高い復元性、デプロイの高速化などが挙げられます。このように、機能をより早く開発し推進できるようになりましたが、アプリケーションとセキュリティのチームは、開発速度を落とさないようにしながら、ガバナンスとコントロールを実施するという新たな課題に直面することとなりました。
お客様の一般的なユースケースの 1 つとしては、環境に応じたアプリケーション アーティファクトの、それぞれ違うレベルのガバナンスを維持するということがあります。デベロッパーは、本番環境に移行する前は、イメージ アーティファクトのデプロイについて自律性を持っていると言えますが、本番環境のリリースでは、一元化され承認されたアーティファクト リポジトリからデプロイしなければならない場合もあります。Binary Authorization と Artifact Registry を使えば、組織は環境ごとに管理レベルを簡単に定義し、SLSA のフレームワークや業界における成熟度の厳しい基準を満たすことができます。
Cloud Run と Google Kubernetes Engine は、Google Cloud の一元化されたワークロードにおいて、よく使用されるランタイムの 2 つです。両方とも Binary Authorization と Artifact Registry に統合されており、改善されたエンドツーエンドのセキュリティに対応しています。ソリューションをシンプルに説明するため、この記事では Cloud Run をメインにご紹介します。プロセスの概略を述べる前に、Artifact Registry と Binary Authorization の概要と、これらが Google Cloud のエコシステムにどのように適合するのかをご説明したいと思います。
Artifact Registry とは
Artifact Registry は、Google Cloud のイメージやアプリケーションのアーティファクトを保存、配布するための推奨サービスです。パッケージや Docker コンテナ イメージを 1 か所で保存、管理できる場所として機能します。Artifact Registry は、Cloud Build やその他の継続的デリバリーおよび継続的インテグレーション システムと統合して、ビルドからパッケージを保存します。ビルドとデプロイに使用できる信頼性の高い依存関係を保存することもできます。
Binary Authorization とは
Binary Authorization は、コンテナベースのアプリケーションにソフトウェア サプライ チェーンのセキュリティを提供する Google Cloud のサービスです。Binary Authorization を使用すると、サポートされているコンテナベースのプラットフォームのいずれかにコンテナ イメージをデプロイするときに適用されるポリシーを構成できます。Cloud Run や GKE などのコンテナ プラットフォーム サービスに、許可されたコンテナ イメージのみがデプロイされるように、セキュリティ管理の追加レイヤを提供します。
デプロイ管理の設定
これらのサービスについてご理解いただけたところで、それらを Cloud Run と組み合わせてどのように使用し、アプリケーション デプロイにガバナンス管理を適用できるかを概説します。
ベスト プラクティスは、組織のポリシーと Binary Authorization ポリシーのガバナンス管理の範囲を決定することです。組織のポリシーでは、Binary Authorization を本番環境プロジェクトなどの特定のプロジェクトで行うか、特定のフォルダや組織内のすべてのプロジェクトで行うかを定義できます。Binary Authorization ポリシーにおいてユーザーは、Artifact Registry 内の特定の承認済みリポジトリ、または本番環境プロジェクトなどの承認済みプロジェクト内のすべてのリポジトリからデプロイを適用する柔軟性を付与されます。一般的なユースケースとしては、特定のプロジェクトに組織のポリシーを適用し、単一のリポジトリに Binary Authorization ポリシーを適用することでしょう。
ステップ 1: Artifact Registry で一元化されたリポジトリを作成する
組織のニーズに合わせ、1 つ以上の承認済みリポジトリを作成し、デプロイが許可されたすべてのイメージをホストできます。こうしたリポジトリで脆弱性スキャンを有効にし、既知の脆弱性がないかどうか、自動的にイメージがモニタリングされるようにしておくのをおすすめします。 コンテナ イメージを承認済みのリポジトリに push し、リポジトリの URL パターンをメモしておきます。
ステップ 2: Cloud Run に Binary Authorization を要求する
すべての Cloud Run サービスが Binary Authorization ポリシーを使用するように要求するには、「許可される Authorization のポリシー（Cloud Run）」の組織のポリシーを構成する必要があります。対象に応じて、組織レベル、フォルダレベル、またはプロジェクト レベルで適用できます。これにより、デプロイされた Cloud Run サービスが Binary Authorization ポリシーを回避して実施されることはありません。
ステップ 3: Binary Authorization ポリシーを作成する
Binary Authorization ポリシーは、プロジェクトごとに作成されます。現時点では、1 つのプロジェクトにおいて作成できるポリシーは 1 つのみです。ポリシーは、プロジェクトが実行される環境の機密性に基づいてカスタマイズする必要があります。開発プロジェクトでは、ポリシーがまったく定義されていない場合もあります。テスト プロジェクトやステージング プロジェクトでは、1 つ以上の承認されたリポジトリの場所からのデプロイを許可する除外ポリシーにより、デフォルトですべてのイメージを無効にできます。除外ポリシーのイメージ パターンに合致するコンテナ イメージは、Cloud Run へのデプロイを許可されます。本番環境プロジェクトのポリシーは、ステージング プロジェクトとほぼ同様ですが、すべてのイメージが組織内の権限者により署名および証明されなければならないという追加の要件があります。
ポリシーの構文は多様なシナリオに対応していますが、出発点としては、以下のように完全修飾されたリソース名を使用して、特定のリポジトリからのイメージのみを許可するというポリシールールも考えられます。
ステップ 4: 「ブレークグラス」イベントの Cloud Audit Logs をプロアクティブにモニタリングする
先に構成した Binary Authorization の組織のポリシーに違反する Cloud Run サービスをデプロイしようとすると、エラーが発生します。このエラーは、違反の詳細を示しており、「ブレークグラス」オプションを提供します。これにより、適切な権限を持つユーザーは、実施中の Binary Authorization ポリシーをオーバーライドできます。デプロイがポリシーを準拠しているか否かに関係なく、すべてのブレークグラス イベントは Cloud Audit Logs に記録されます。管理者は、Cloud Operations スイートのログベースのアラートを使用して、ブレークグラス イベントの適切なチャネルへの通知をプロアクティブに構成できます。
まとめ
Artifact Registry と Binary Authorization により、Google Cloud ユーザーは、コンテナ イメージのガバナンス向上のための柔軟な追加セキュリティ レイヤを使用できるようになりました。コンテナのランタイム環境全体において、何がデプロイできるかを管理するのも容易になります。このように、組織はセキュリティ対策の成熟度や環境ごとの要件に応じて、基本的なポリシーから高度なポリシーまで幅広くデプロイできます。今までご説明してきたこうした実装は、Google Kubernetes Engine および Anthos のデプロイに適用できます。また、継続的検証、特定のルール、Google システム イメージの除外などの Binary Authorization の追加設定も利用できます。Binary Authorization について詳しくは、Google のドキュメントをご覧ください。
- カスタマー エンジニア NJ Njoku
- プロダクト マネージャー Preston Holmes
