セキュアな GKE クラスタを構築するために知っておきたいポイント 2022 年夏（前編）
はじめに
Kubernetes クラスタやその上で動くワークロードに対する脅威は多様化しており、クラスタ コンポーネントだけではなくコンテナ アプリケーションやソフトウェア サプライチェーンも含めた多層的な防御が求められます。
Google Cloud では Google Kubernetes Engine (以降 GKE) やその周辺エコシステムにおけるセキュリティ機能が活発に開発されており、これらの機能を上手く活用することで Kubernetes 環境の多層防御を実現可能です。
とはいえ、Google Cloud で提供している コンテナ セキュリティ関連機能 / サービスは種類が多すぎて何がなんだか分からない方も多いのではないでしょうか。本記事では、GKE 周辺のセキュリティ機能 / サービスの概要や使い所、おすすめの設定等について紹介していきます。
ちなみに本記事は Cloud Native Security Conference 2022 で発表した内容とほぼ同じです（なのでスライド画像を多用しています）。諸般の事情によりイベントの登壇アーカイブが残せないため、アーカイブの代わりとしても使えるようブログ記事として公開しています。
GKE のアーキテクチャ
まず最初におさらいも兼ねて GKE のアーキテクチャについて説明します。
GKE は Google Cloud が提供するマネージドの Kubernetes です。Kubernetes をより簡単に運用するための各種自動化機能を有しています。また高いスケーラビリティや豊富なセキュリティ機能を提供している点も特徴的です。
GKE は大きく Control Plane と Node というコンポーネントに分かれます。GKE は現在 2 種類のモードが存在しており、Control Plane が Google 管理となり Node はユーザー管理となるクラスタが GKE Standard (従来の GKE)、一方 Control Plane に加えて Node も Google 管理となるクラスタが GKE Autopilot となります。GKE Autopilot の特徴については本記事後半で触れますのでここでは割愛します。
GKE は Standard / Autopilot どちらのモードにおいても、Control Plane が Google 管理となるため、利用者側で Control Plane におけるセキュリティ対策やスケーラビリティなどを考慮しなくても運用できるようになっています。
本記事では主に GKE Standard を対象に話を進めていきます。
Kubernetes 環境に潜むリスク
冒頭でもお伝えした通り、Kubernetes やその周辺エコシステムは様々なコンポーネントから構成され複雑になっており、その攻撃手法も多様化しています。
例えば、Kubernetes 環境に潜むリスクとして以下が考えられます。
- Control Plane や Node 等 Kubernetes クラスタ コンポーネントの脆弱性や設定ミスが悪用されるリスク
- コンテナ アプリケーション自体に含まれた脆弱性や設定ミスが悪用されるリスク
- 信頼できないリポジトリを利用し、マルウェアや脆弱性が含まれるソースコード・コンテナイメージをデプロイしてしまうリスク、等
これらリスクに対処するためには、Kubernetes 環境を構成する各要素・レイヤでの防御が重要となってきます。
今回は前編後編に分けて Google Cloud 上で Kubernetes 環境を安全に運用するために役立つ機能/サービスを以下カテゴリに分けて紹介していきます。
- クラスタ セキュリティ
- ソフトウェア サプライチェーン セキュリティ
- ワークロード セキュリティ
- 不適切な設定の検出
※全てのカテゴリを1つの記事で書いてしまうと長くなりすぎそうでしたので「1. クラスタ セキュリティ」を前編（本記事）で紹介し、残りは後編で紹介します。
クラスタ セキュリティ
まずは GKE クラスタ自体のセキュリティの検討ポイントについてご紹介します。
リスクとして紹介した「Control Plane や Node 等 Kubernetes クラスタ コンポーネントの脆弱性や設定ミスが悪用される」可能性を考えると、各クラスタコンポーネントへの不要なアクセス自体を防ぎそもそもの攻撃の機会を減らすことや、脆弱性に即座に対応するための仕組みを用意することが重要になってきます。
このカテゴリではクラスタセキュリティを以下に細分化して紹介します。
- クラスタのアクセス制御（経路制御、適切な認証認可）
- クラスタのアップグレード（脆弱性対策）
- ノード セキュリティ（仮想マシン、OS、ランタイムのセキュリティ）
クラスタのアクセス制御（経路制御、適切な認証認可）
攻撃リスクを減らすために重要なポイントの 1 つとして GKE クラスタのコンポーネント (Control Plane や Node) に対するアクセス可能な経路を絞るということが考えられます。これにより不要なアクセス経路を塞ぐことができ、そもそもの攻撃の機会を減らすことが可能になります。
クラスタ コンポーネントへのアクセス経路の制御方法として活用いただける機能が限定公開クラスタ（プライベート クラスタ) です。限定公開クラスタとは Node に Public IP が付与されていない (Private IP のみが付与される) クラスタであり、インターネットなど外部ネットワークから Node に対して直接アクセスされるリスクを低減することが可能です。
限定公開クラスタは Control Plane の公開設定により、さらに以下 3 種類に分類することができます。
「① パブリック エンドポイント有効」は Node には Public IP が付与されていないのですが、Control Plane には Public IP が付与されておりどこからでもアクセスができる状態になっています。3つの選択肢の中で最も利便性は高いのですが、ネットワーク的には誰でも Control Plane にアクセスできる設定となっている点は注意が必要です。
一方、「② パブリック エンドポイント有効 + 承認済みネットワーク」は①と同じく Control Plane に Public IP が付与されているのは変わりませんが、承認済みネットワークという機能によりControl Plane にアクセス可能な Source IP アドレスレンジを絞ることができます。 (現状、承認済みネットワークでは許可されたアドレスレンジ以外にも Cloud Run や Cloud Functions からもアクセス可能になっていますが、このアクセス経路は今後削除される予定です）
これにより、例えばオフィスやデータセンターなど特定の場所からのアクセスのみ許可することができるようになるため①のオプションに比べると安全に運用ができます。
そして最後の「③ パブリック エンドポイント無効」は、Node だけではなく Control Plane も Public IP を付与しないというオプションになります。これによりユーザー VPC 内のマシンや Cloud Interconnect/Cloud VPN 経由で接続されたオンプレミス ネットワークからのみのアクセスに絞ることができます。採用にあたっては利便性とのバランスも考慮した方が良いとは思いますが、3 つの中で一番固い設定はこちらです。
次はクラスタに対する認証認可の話です。GKE は Google Cloud の IAM という仕組みを使って認可を制御することができます。
クレデンシャルの流出や内部犯が悪意を持った設定をするようなケースを考えると、（基本的な話にはなりますが）必要な人にのみ必要最小限の権限を付与するのをお勧めしています。
特に本番環境であれば、Zero Touch Production (ZTP) のような考え方に沿って人間が本番環境を直接触ることを避ける（なるべくユーザーアカウントに対して変更権限を与えない）というのを検討いただくのも良いかもしれません。人が直接 GUI や kubectl を叩く運用を可能な限り減らし、基本的には IaC や CI/CD など自動化された仕組みを使って本番環境の設定変更を行うことで障害やセキュリティリスクを減らすこともできます。
IAM の話に戻りますが、最近 GKE でも利用可能になったリソースタグを活用すると、IAM Policy や組織ポリシーの条件としてタグが利用可能になります。
これにより、同一プロジェクト内のクラスタに対してもより細かく権限の制御やポリシーの適用が可能になりました。例えば同一プロジェクトの複数環境のクラスタが混在しているケースなど、活用できそうな場面があれば利用を検討いただくのも良いかもしれません。
ちなみに「ラベル」と「タグ」の違いは以下のようになっています。
GKE クラスタの作成/削除など Google Cloud API を利用する操作については IAM で権限を制御しますが、Kubernetes クラスタ内オブジェクトの操作については Kubernetes の RBAC を使って制御します。
運用をシンプルにするために、 RBAC は個々のユーザー単位ではなくグループ単位で設定することをお勧めしているのですが、これは最近 GA になった Google Groups for RBAC という機能を使うことで実現できます。 (ちなみに IAM のロール付与もユーザー単位ではなくグループ単位で設定するのをお勧めしています)
また、脆弱性などを突かれ攻撃者が Node を自由に触れるようになったり、運用者の誤操作による他 Google Cloud サービスへの影響を極小化するため、GKE Node 自体が持つ権限の考慮も必要です。
GKE Node から他の Google Cloud サービスへは Node に設定されたサービスアカウントの権限を使ってアクセスすることができます。注意点として、GKE Node のデフォルト サービスアカウントには強い権限 (Editor 権限) が付与されているため、システムとして必要最低限の権限を付与したサービスアカウントを別途作成し設定することをお勧めしています。
アプリケーション (Pod) から他の Google Cloud サービスへのアクセスについては Workload Identity という機能で制御が可能です。Workload Identity を使うと Google Cloud のサービスアカウントと GKE 内の K8s サービスアカウントを紐づけ、サービスアカウントキー無しで Pod から Google Cloud サービスへアクセス可能になります。サービスアカウントキーをクラスタ内で保管する必要がなくなるため、キーの流出やそれによる不正利用のリスクを少なくすることができます。
また、GKE では安全でない認証認可設定がデフォルトで無効化されています。この辺りは特別な要件がない限りはそのままデフォルト設定にしておくのを推奨しています。
クラスタのアップグレード
Kubernetes / GKE では脆弱性の対応や既知問題の修正、新機能の導入のためにアップデートを頻繁にリリースしています。特にセキュリティの観点では、いかに迅速に脆弱性に対応できるかが重要となっており、継続的なアップグレード戦略を検討する必要があります。
先述の通り GKE では Control Plane を Google が管理しており、自動的にパッチ適用・アップグレードされる（無効化不可）のですが、Node については自動もしくは手動でアップグレードを行う必要があります。
GKE クラスタのバージョン指定方法は大きく以下 2 種類に分かれているのですが、Control Plane だけでなく Node も含めてアップグレード・パッチ適用を自動的に管理してくれるリリース チャンネルを選択いただくのをお勧めしています。
リリース チャンネルは Rapid, Regular, Stable という 3 つのチャンネルから構成されており、本番環境での利用を想定する場合は安定性の面から Regular もしくは Stable をお勧めします。
また、クラスタ通知機能を活用することにより、新バージョンが利用可能になったり新しい脆弱性情報が見つかった際に自動的に通知してくれるようになります。
GKE 全体に関する脆弱性情報はリリースノートや Security bulletins に集約されていますのでこちらもご確認いただくのが良いと思います。
クラスタ通知機能は設定した対象のクラスタに関する脆弱性情報などを通知してくれるのに対し、リリースノートや Security bulletins では自分のクラスタが利用しているバージョン以外も含めた情報を確認できます。
Node セキュリティ
GKE Node にも複数のセキュリティオプションが用意されていますので、それぞれ簡単に説明していきます。
まず Shielded GKE Nodes とは Shielded VM を GKE のノードとして利用可能にするオプションです。デフォルトで有効化されているのでそこまで気にされてない方も多いかもしれませんが、Shielded GKE Nodes を有効化すると、攻撃者がノードのブートストラップ認証情報を抜き取った場合でも、攻撃者によるノードになりすましを防ぐことができるようになります。デフォルトのまま有効化にしておくことをお勧めします。
ちなみに Shielded GKE Nodes の機能の中でも「整合性モニタリング」という機能はデフォルト有効化になっているのですが、「セキュアブート」はデフォルトで有効化されていません。
理由としてはセキュアブートが有効であるとサードパーティの未署名カーネル モジュールを読み込めないため、デフォルトとしては無効になっています。もしそういったカーネルモジュールを利用しない場合は有効化していただくのがお勧めです。
続いて Confidential GKE Nodes です(2022.06 に GA しました)。これは Confidential VM を GKE Node として利用できるオプションです。有効化することにより、GKE Node 上で処理中のデータも暗号化することが可能となります。
一方、利用することによる制限事項もいくつか存在するため、高い機密性が求められる、かつ制限事項を許容できるようなワークロードでの利用をご検討ください。
GKE Sandbox は gVisor ベースの Node を利用するオプションです。gVisor はユーザー空間で動作するゲストカーネルで、コンテナからの syscall をインターセプトしホストカーネルへの直接アクセスを制限することにより、ワークロードとホストカーネルを分離します。
特にマルチテナントで構成されるクラスタや、信頼できないワークロードが実行される可能性のあるクラスタなどで有用な機能です。
注意点としては GKE Sandbox ではサポートされていない機能がいくつかあるため、必要な機能がサポートされているかは事前にご確認いただく必要があります。（ちなみに以前は GKE Sandbox では Istio がサポートされていなかったのですが、GKE 1.18 以降ではサポートされています）
GKE の Node OS は Container-Optimized OS (COS)、Ubuntu、Windows から選ぶことができますが、セキュリティの観点では COS を利用していただくことを推奨しています。
COS はコンテナ実行に最適化された OS です。最低限のプロセスのみが動作しておりアタックサーフェスを小さくすることができる他、各種セキュアな設定がデフォルトで組み込まれているため OS に特別な要件が無い限りは COS を選んで頂くのをお勧めします。
もっと楽にセキュアなクラスタを手に入れたいあなたに
ここまで色々な GKE のセキュリティ関連機能を紹介してきましたが、考慮すべきポイントが多くて大変だという方もいらっしゃるのではないでしょうか。
そんなあなたにおすすめなのが、GKE Autopilot です。
本記事の冒頭で説明した通り、GKE Autopilot は Control Plane だけでなく Node も Google が管理する方式のクラスタです。ただ Node を管理しなくても良くなるオプションというわけでもなく、実は Autopilot には各種 GKE のベストプラクティスがデフォルトで設定されています。
特にセキュリティに関しては、以下の特徴 (制約とも言う) を持っています。特に Node への SSH ができないというのは、ノードへの攻撃リスクを下げるという意味でも特徴的な仕様かと思います。
他にも GKE Standard と Autopilot を比べると以下のような違いがあります。Workload Identity や Shielded GKE, セキュアブートなどこれまで紹介してきた機能がデフォルトで有効化されておりかつ無効化が不可となっています。
制約も色々とあるため、全てのワークロードに適しているというものでもありませんが、GKE Autopilot はセキュリティのベスト プラクティスに沿った構成を簡単に使い始めることができるので、これから GKE を始める（そしてなるべくセキュリティも含めた運用コストをかけたくない）という方にもお勧めです。
前編まとめ
前編では「クラスタのアクセス制御」「アップグレード（脆弱性対応）」「ノードセキュリティ」の観点で GKE の各機能を紹介してきました。
GKE クラスタにはさまざまなセキュリティ オプションが存在しているため、求められるセキュリティ要件や利用したい機能、利便性等を考慮しながら適した構成を選択していただくのが良いと思います。
また、Autopilot クラスタは GKE の各種ベストプラクティス設定がビルトインされていて簡単に Production Ready なクラスタを使い始めることができますので、要件に合いそうでしたらぜひ利用してみてください。
後編では、以下のトピックに関係する Google Cloud のサービスを紹介していきますので、ぜひそちらもご覧ください。
- ソフトウェア サプライチェーン セキュリティ
- ワークロード セキュリティ
- 不適切な設定の検出
