はじめに

モダンな開発において、CI/CDによるデプロイの自動化は一般的になりました。しかし、自動化が進む一方で、運用上の不安やセキュリティレベルの維持に課題を感じる場面も少なくありません。

参画するプロジェクトでコンテナイメージのウイルス・マルウェア対策という非機能要件に向き合っており、単にスキャンを実行するだけでなく、スキャンで問題が見つかった場合にデプロイを確実に阻止するための実装レベルでの統制方法がないかを検討していました。

そんな中、Google CloudのProfessional Cloud Architect (PCA) や Professional Cloud Security Engineer (PCSE) 受験の学習を進める中で Binary Authorizationを知り、実務への活用に関心を持ちました。

📘 Binary Authorizationの概要
https://docs.cloud.google.com/binary-authorization/docs/overview?hl=ja

脆弱性スキャンでNGが出たイメージがデプロイされたり、サービスA用のイメージを誤ってサービスBに適用してしまったり、あるいはビルドパイプライン外で作られた出所不明なイメージが紛れ込んだりといったリスクは、人の注意や運用ルールだけで防ぎ切るのは困難です。こうした課題をシステム的に解決し、デプロイを制御する仕組みがBinary Authorizationです。今回は、Cloud Runでの利用に焦点を当てた活用方法を検討してみました。

Binary Authorizationの基本概念

Binary Authorizationは、信頼できる署名が付与されていないコンテナのデプロイを拒否するゲートキーパーの役割を果たします。

内部的にはContainer Analysis APIのメモ（Note）とオカレンス（Occurrence）という仕組みを利用しています。これはBinary Authorization API における「認証者」と「証明書」のコンセプトが、それぞれ Container Analysis API の「メモ」と「オカレンス」を使用して実装されている、ということのようです。

  • 認証者: 脆弱性スキャン合格やQA承認済みといった、承認の主体（Attestor）を定義します。
  • 証明書: 特定のイメージに対して実際に生成されたデジタル署名（Attestation）を指します。

デプロイ時には、ポリシーで指定した認証者の署名（証明書）がイメージに付与されているかを確認し、条件を満たしていない場合はデプロイを物理的にブロックします。

想定している活用シナリオ

Binary Authorizationの導入によって具体的にどのようなリスクを防げるのか、すべてのパターンを試行できているわけではありませんが、実務への適用に向けて検証を検討している3つのユースケースを挙げます。

1. 脆弱性のあるイメージのブロック

Artifact Registryの自動スキャン結果と連動させる方法です。CI/CDパイプラインの中でスキャンを実行し、致命的な脆弱性が0件という条件をクリアしたときのみ、最後に署名を付与するように構成することを想定しています。これにより、脆弱性が残るイメージは署名を得られないため、環境へのデプロイを未然に防げるのではないかと考えています。

2. デプロイ先の取り違え防止

サービスごとに専用の認証者を用意する手法です。サービスAのCloud RunにはAの署名が必要というルールを設定しておけば、たとえ有効な署名を持っていても、B用のイメージがAにデプロイされることはないはずです。認証者の種類までチェックの対象とすることで、取り違えによる事故を確実に防止できる仕組みとして採用できないかと考えています。

3. 外部セキュリティスキャンとの連携

冒頭で触れたウイルス・マルウェア対策についても、この仕組みでの対応を検討しています。Google Cloudには現状コンテナのマルウェアをスキャンするサービスはありませんが、外部のサービスを使用してマルウェアスキャンを行い、スキャンが完了して合格判定が出たタイミングでGoogle Cloud上の署名プロセスを動かすような構成です。Binary Authorizationは署名の有無を確認するため、スキャン自体がどこで行われたかは問いません。外部チェックをデプロイの必須条件として組み込める柔軟性があると考えています。

導入のステップ

運用の現場では、いきなりデプロイをブロックすることに抵抗があるかもしれません。その場合はドライランモードから段階的に導入するのが現実的かと思います。
運用が安定した段階でドライランモードを無効化することで、スムーズに移行することができそうです。この辺りはWAFを適用する際の手順と同じですね。

緊急時のデプロイ強行（Breakglass機能）

例えば、本番環境で深刻な障害が発生し、即座にパッチを適用したコンテナをデプロイする必要がある状況で、CI/CDパイプライン、Artifact Registryの自動スキャン、あるいは連携しているマルウェアスキャン基盤のいずれかに障害が発生していると、証明書が生成されずデプロイがブロックされる危険性があります。

このような事態を回避するため、Binary Authorizationにはブレイクグラス（Breakglass）と呼ばれる緊急迂回機能が備わっています。ブレイクグラスは特定の高い権限を持つ運用管理者が、証明書の有無を意図的に無視して強制的にコンテナをデプロイできる機能です。
ブレイクグラス機能を使用してデプロイが実行された場合、そのイベントがCloud Audit Logsに記録され追跡可能となります。

終わりに

これまでに起こしてしまった問題や、検討していた要件に対してとても有効なサービスであると考えており、実践投入に向けて検証を進めたいと考えています。

試験のための勉強が業務に結びつくため、学習意欲が高まりますね。次は何を受験しようかな。