このページでは、Google Kubernetes Engine（GKE）Autopilot モードのセキュリティ機能、構成、設定について説明します。この情報は、Google が Autopilot モードで適用するセキュリティ制約と、Autopilot で使用可能なセキュリティ機能を理解しようとするセキュリティ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
このページを読む前に、次の内容を理解しておいてください。
用語
GKE では、Autopilot クラスタを作成するか、任意の Standard クラスタの Autopilot ComputeClass でワークロードを実行することで、Autopilot を使用できます。このページでは、次の用語を使用して、これらの両方の状況における Autopilot のセキュリティ対策について説明します。
- Autopilot クラスタ
- クラスタ全体で Autopilot モードが使用されています。
- Standard クラスタの Autopilot ワークロード
- クラスタは Standard モードを使用し、ComputeClasses を使用して Autopilot で特定のワークロードを実行します。
Autopilot のセキュリティ対策
GKE では、セキュリティの概要とクラスタのセキュリティの強化に記載されている多くの推奨事項をはじめとして、さまざまなセキュリティのベスト プラクティスと設定が Autopilot モードではデフォルトで適用されます。
Autopilot クラスタでは、GKE によりこのページのすべての対策がデフォルトで厳密に適用されます。このデフォルト構成により、Autopilot クラスタは GKE の推奨される使用方法になります。Standard クラスタの Autopilot ワークロードの場合、GKE では次のセクションのセキュリティ対策がベスト エフォート ベースで適用されます。
Kubernetes Pod セキュリティ標準の適用
Kubernetes プロジェクトには、Pod セキュリティ標準という名前の、次のポリシーを定義する一連のセキュリティ ガイドラインがあります。
- 特権: アクセス制限はありません。Autopilot では使用されません。
- ベースライン: 既知の権限昇格経路を防止します。これによれば、ほとんどのワークロードを大幅な変更を行わずに実行できます。
- 制限付き: 最高レベルのセキュリティです。ほとんどのワークロードに大きな変更が必要となります。
Autopilot モードでは、GKE は Kubernetes アドミッション コントローラを使用して Pod のセキュリティ制約を適用します。デフォルトの Autopilot Pod のアドミッション ポリシーには、Pod セキュリティ標準のベースライン レベルの推奨事項がすべて含まれていますが、ユーザビリティを考慮して一部が変更されています。また、デフォルトの Autopilot のアドミッション ポリシーには、Pod セキュリティ標準の制限付きレベルで多くの制約が含まれていますが、ワークロードの大部分の実行をブロックするような制限は回避しています。
制限付きのポリシーを完全に遵守するために、追加の制限を適用する場合は、必要に応じて特定の Namespace で PodSecurity アドミッション コントローラを使用できます。
次の表に、デフォルトの Autopilot アドミッション ポリシーのコントロールと、Pod セキュリティ標準のベースライン レベルおよび制限付きレベルのコントロールの比較を示します。この表の各コントロールの詳細については、Pod のセキュリティ標準の対応するエントリをご覧ください。
コンプライアンスを評価する際には、制約が独自のワークロードにどのように適用されるかを考慮しました。これには、検証済みの Google Cloud パートナーのワークロードと、機能するために特定の権限を必要とするシステム ワークロードは含まれません。
| 管理 | ベースライン ポリシーの遵守 | 制限付きポリシーの遵守 | その他の情報 |
|---|---|---|---|
| HostProcess | Autopilot が HostProcess をブロックします。 | ||
| ホスト名前空間 | Autopilot はホストの名前空間をブロックします。検証済みのパートナーの一部のコンテナでは、ホストの名前空間を使用できます。 | ||
| 特権コンテナ | Autopilot は、デフォルトで特権付きコンテナをブロックします。Autopilot を使用すると、検証済みのパートナーの特権コンテナを、セキュリティ ツールやモニタリング ツールの実行などに使用できます。 | ||
| Linux 機能 | Autopilot ワークロードは、デフォルトでは Baseline Pod Security Standard で指定された機能にのみアクセスできます。 次の機能を手動で有効にできます。
Autopilot では、一部の確認済みパートナー ワークロードで、ドロップされた機能も設定できます。 |
||
| HostPath ボリューム | 一部準拠 | 一部準拠 | Autopilot では、コンテナはデバッグのために /var/log への読み取り専用アクセス権をリクエストできますが、他のすべての読み取りまたは書き込みのアクセス権は拒否します。 |
| HostPorts | 特定のホストポートの設定は許可されません。これにより、一部のスケジューリングの問題が軽減され、偶発的または意図的なサービスのネットワークへの直接公開を防ぐことができます。既知の範囲からのランダムなホストポートの割り当てを手動で設定して、ゲームサーバーなどの直接接続のネットワーキング アプリケーションをサポートできます。 | ||
| AppArmor | AppArmor の docker-default セキュリティ プロファイルは、Container-Optimized OS に自動的に適用されます。 | ||
| SELinux | AppArmor がすでに適用されているため、SELinux は適用されません。SELinux は、Pod セキュリティ標準でも必須ではありません。 | ||
/proc マウントタイプ |
GKE バージョン 1.33 以降では、Pod securityContext で procMount が Unmasked に設定されている場合、Autopilot は Pod を拒否します。1.33 より前のバージョンでは、Autopilot は procMount フィールドの値を Default に自動的に上書きします。 |
||
| seccomp プロファイル | Autopilot は、RuntimeDefault seccomp プロファイルをすべてのワークロードに適用します。Pod 仕様でプロファイルを Unconfined に設定することによって、特定のワークロードについてこの設定を手動でオーバーライドできます。 |
||
| sysctls | GKE では --allowed-unsafe-sysctls kubelet フラグが設定されないため、安全でない sysctls を持つ Pod はスケジュールに失敗します。保護を強化するため、2023 年 7 月 11 日の時点で、新しい 1.27 以降のクラスタには、securityContext 設定を適用し、安全でない sysctls を使用する Pod を拒否するポリシールールも設定されました。 | ||
| Volume のタイプ | Autopilot では、制限付きポリシーのボリューム タイプのみが許可されます。ただし、デバッグ用の /var/log への読み取り専用アクセス権を持つ HostPath ボリューム、Compute Engine 永続ディスク用の gcePersistentDisk、ネットワーク ファイル システム ボリューム用の nfs が追加されます。 |
||
| 権限昇格 | この設定では、root として実行されていないコンテナのみが保護されます。業界調査によると、コンテナの 76% は root として実行されているため、Autopilot を使用すると、root で実行するとほとんどのワークロードが実行可能になります。現在、この設定は、ファイルシステムの機能を使用して Kubernetes の root 機能の処理不足を回避するために、ワークロードを非 root に制限するためにも有効です。 | ||
| 非 root で実行 | 業界調査によると、コンテナの 76% は root として実行されているため、Autopilot を使用すると、root で実行するとほとんどのワークロードが実行可能になります。 | ||
| 非 root ユーザーとして実行 | コンテナは runAsUser を 0 に設定できます。業界調査によると、コンテナの 76% は root として実行されているため、Autopilot を使用すると、root で実行するとほとんどのワークロードが実行可能になります。 |
組み込みのセキュリティ構成
Pod セキュリティ標準に加えて、Google は業界のベスト プラクティスと Google の専門知識に基づいて、Autopilot に多くのセキュリティ設定を適用しています。これらの組み込みのセキュリティ構成は、Autopilot クラスタに厳密に適用されます。Standard クラスタの Autopilot ワークロードの場合、Google はこれらの構成をベスト エフォート ベースで適用します。ただし、次の表に示す例外がいくつかあります。
次の表に、Autopilot によって適用されるセキュリティ構成の一部を示します。
| 構成 | 説明 |
|---|---|
| ホスト オプション |
|
| Linux 機能 | 次の Linux 機能を使用できます。 "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" 次の機能を手動で有効にすることもできます。
|
| 特権コンテナ | コンテナは、Google Cloud パートナーがデプロイする場合を除き、特権モードでは実行できません。特権コンテナは、kubelet の変更など、基盤となるノードへの変更を加えることができます。このアクセスにより、Pod の不正使用の影響が大きくなる可能性があります。 |
| GKE が管理する名前空間 | セキュリティ対策として、Autopilot では GKE が管理する名前空間（kube-system など）にワークロードをデプロイできません。 |
| コンテナの分離 | Autopilot は、コンテナ エスケープの脆弱性による影響を制限するため、コンテナに次の制限を適用します。 Linux 機能とカーネル セキュリティ
|
| Pod レベルのセキュリティ ポリシーの適用 | Autopilot は、PodSecurity アドミッション コントローラ、Gatekeeper、Policy Controller などの Pod レベルのセキュリティ ポリシー用の適用メカニズムをサポートしています。ただし、このページで説明する組み込みセキュリティ構成で要件がすでに満たされている場合は、これらを使用する必要はありません。 |
| ノードへの SSH 接続 | Autopilot はノードへの SSH アクセスをブロックします。ノードの健全性や、ノード上で実行されているすべての Kubernetes コンポーネントに関する処理など、ノードのすべての運用面は GKE によって処理されます。 Kubernetes の |
| ユーザーのなりすまし | Autopilot は、すべてのユーザー定義のユーザーとグループを対象としてユーザーのなりすましに対応しています。 Autopilot クラスタでのみ、システム ユーザーとグループ（ |
| 動的アドミッション Webhook の変更 | Autopilot クラスタでのみ、GKE は変更用 Webhook を変更して、 Autopilot は、次のリソースの 1 つ以上、あるいはそのリソースのサブリソースを指定する Webhook も拒否します。 - group: "" resource: nodes - group: "" resource: persistentVolumes - group: certificates.k8s.io resource: certificatesigningrequests - group: authentication.k8s.io resource: tokenreviews リソースまたはグループに |
| ValidatingAdmissionPolicies | Autopilot クラスタでのみ、GKE は Autopilot は、次のリソースの 1 つ以上、あるいはそのリソースのサブリソースを指定する - group: "" resource: nodes - group: "" resource: persistentVolumes - group: certificates.k8s.io resource: certificatesigningrequests - group: authentication.k8s.io resource: tokenreviews リソースまたはグループに |
| 証明書署名リクエスト | Autopilot で CertificateSigningRequest を作成して、クラスタ認証局によって署名された証明書を作成できます。システム コンポーネントとの干渉を防ぐため、Autopilot クラスタは、既知の特権 ID（システム グループ、システム エージェント、Google マネージド IAM サービス エージェントなど）に対する CertificateSigningRequests を拒否します。この制約は Standard クラスタには適用されません。Standard クラスタでは、既知の特権 ID の CertificateSigningRequest を作成できます。 |
| GKE のセキュリティ機能 | Autopilot クラスタを使用すると、推奨される GKE セキュリティ機能が有効になります。有効なセキュリティ機能とオプションのセキュリティ機能のリストについては、Autopilot のセキュリティ機能をご覧ください。 |
| ノードのオペレーティング システム | Autopilot は、ノードのオペレーティング システムとして containerd を含む Container-Optimized OS を使用します。Container-Optimized OS は Google によって作成、管理されます。 |
| GKE バージョンのアップグレード | Autopilot クラスタは作成時点で GKE リリース チャンネルに登録され、自動アップグレードが常に有効です。Google は、コントロール プレーンとノードを、リリース チャンネルの最新の認定バージョンに自動的にアップグレードし続けます。 |
Autopilot のセキュリティ境界
Autopilot は Kubernetes API へのアクセスを提供しますが、特権 Pod など一部の特権レベルの高い Kubernetes 機能を使用する権限を削除します。これは、ノードの仮想マシン（VM）へのアクセス、変更、直接制御の機能を制限することを目的としています。Autopilot は、これらの制限を実装して、ワークロードがノード VM に対する低レベルのアクセス権を付与されないようにするので、Google Cloud はノードを完全に管理し Pod レベルの SLA を実現できます。
Google の目的は、ノード VM への意図しないアクセスを防ぐことです。Google では、Google 脆弱性報奨金プログラム（VRP）でセキュリティ効果に関する報告を受け付けています。優れた報告に対しては Google VRP リワードパネルの裁量で報奨金を提供しています。
設計上、クラスタ管理者などの特権ユーザーは GKE クラスタを完全に制御できます。Google のマルチテナンシーのガイダンスで説明されているように、セキュリティの観点から、強力な GKE または Kubernetes 権限を広範囲に付与することを避け、可能な限り Namespace の管理者権限の委譲を行うことをおすすめします。
Autopilot は、排他的使用のために、プロジェクトに単一テナント VM をプロビジョニングします。個々の VM 上で、Autopilot のワークロードはセキュリティが強化されたカーネルを共有し、一緒に実行されることがあります。共有カーネルは単一のセキュリティ境界を表すため、高リスクのワークロードや信頼できないワークロードなど強固な分離が必要な場合は、GKE Sandbox Pod でワークロードを実行して、多層的セキュリティを確保することをおすすめします。
ユースケースに基づくセキュリティの推奨事項
以降のセクションでは、ユースケースに応じて Autopilot クラスタのセキュリティを計画、実装、管理するためのリンクを示し、推奨事項について説明します。
クラスタ セキュリティを計画する
| ユースケース | 関連情報 |
|---|---|
| プラットフォームとしての GKE のセキュリティへのアプローチを理解する |
|
| 環境の強化における役割を理解する | 責任共有モデルについて確認する。 |
| セキュリティ強化とインシデント対応に関する Google の推奨事項を確認する |
|
| GKE による監査ロギングの実装方法を理解する |
|
認証と認可
Autopilot クラスタを設定した後、Kubernetes API や Google Cloud APIs などのリソースを使用するために、ユーザーとアプリケーションの認証が必要になることがあります。
| ユースケース | 関連情報 |
|---|---|
| クラスタ API サーバーでユーザーまたはアプリケーションを認証する |
|
| Google Cloud API とサービスに対してアプリケーションを認証する | Autopilot クラスタを使用すると、IAM サービス アカウントとして機能するように Kubernetes サービス アカウントを構成することで、Workload Identity Federation for GKE を使用して、 Google Cloud API に対するワークロードの認証を安全に行うことができます。手順については、Workload Identity Federation for GKE を使用するようにアプリケーションを構成するをご覧ください。 |
| プロジェクト レベルでアクションを認可する | プロジェクト レベルでクラスタ間のアクションを認可するには、IAM を使用します。IAM のロールと権限を使用して、特定の GKE リソースや Kubernetes API リソースへのアクセスを許可または拒否できます。手順については、IAM ポリシーを作成するをご覧ください。 |
| クラスタレベルでアクションを認可する | 特定のクラスタ内の Kubernetes API リソースに対するアクションを認可するには、組み込みの Kubernetes ロールベースのアクセス制御（RBAC）メカニズムを使用します。手順については、RBAC を使用してクラスタ内のアクションを認可するをご覧ください。 |
| 組織レベルでアクションを認可する | Google Cloud の組織のポリシー サービスを使用すると、 Google Cloud組織全体の GKE リソースに対する特定のオペレーションに制約を適用できます。手順については、カスタムの組織のポリシーを使用して GKE リソースに対するアクションを制限するをご覧ください。 |
クラスタとワークロードの強化
事前構成された Autopilot の測定の範囲を超える特殊な分離要件や強化要件がある場合は、次のリソースを検討してください。
| ユースケース | 関連情報 |
|---|---|
| クラスタ エンドポイントへの公開アクセスを制限する | Autopilot クラスタのネットワーク隔離を構成し、クラスタ コントロール プレーンの外部エンドポイントを無効にします。手順については、コントロール プレーンのアクセスを構成するをご覧ください。 |
| 特定のネットワークへのクラスタのアクセスを制限する | コントロール プレーン承認済みネットワークを使用して、クラスタにアクセスできる IP アドレス範囲を指定します。 |
| 機密情報をクラスタ外に保存する | バージョニングが有効になっている外部暗号化ストレージ プロバイダに機密データを保存することは、一般的なコンプライアンス要件であり、おすすめできる方法です。Secret Manager でデータを保存し、GKE 用 Workload Identity 連携を使用して Autopilot クラスタからデータにアクセスします。手順については、GKE 用 Workload Identity 連携を使用して GKE クラスタの外部に保存されている Secret にアクセスするをご覧ください。 |
| クラスタにデプロイする前にコンテナ イメージを確認する | デプロイ時に Binary Authorization を使用して、Pod マニフェストで参照されているコンテナ イメージの整合性を確認します。手順については、Binary Authorization を使用してデプロイ時にコンテナ イメージを検証するをご覧ください。 |
セキュリティ対策をモニタリングする
クラスタを設定してワークロードをデプロイしたら、クラスタのセキュリティ対策を監視できるようにするため、モニタリングとロギングを設定して構成する必要があります。次のすべてを実施することをおすすめします。
- GKE の [Security Posture] ダッシュボードにクラスタを登録して、セキュリティの問題がある構成やコンテナ オペレーティング システム パッケージの脆弱性などのワークロードを監査し、実行可能な緩和策を取得します。
- 新しいセキュリティに関する公開情報の通知を受け取り、クラスタ通知を使用してイベントをアップグレードします。
- Cloud Monitoring の GKE ダッシュボード、または GKE の [オブザーバビリティ] タブを使用して、クラスタを監視します。
- Cloud Logging で GKE 監査ログを表示して管理する方法を学習します。
次のステップ
- GKE セキュリティの概要を確認する。
- GKE セキュリティ強化ガイドを確認する。
- セキュリティに関する公開情報とリリースノートに登録する。