このページでは、GKE の実行時に推奨される Google Kubernetes Engine（GKE）Autopilot のセキュリティ機能、構成、設定について説明します。
このページの対象読者
このページは、Google が Autopilot クラスタに特に適用するセキュリティ制限と、Autopilot で使用可能なセキュリティ機能を理解しようとするセキュリティ管理者を対象としています。
また、GKE セキュリティの概要もご覧ください。ここでは、すべての GKE クラスタ、ネットワーク構成、ワークロードに適用されるセキュリティ強化オプション、対策、推奨事項について説明しています。
Autopilot のセキュリティ対策
Autopilot クラスタは、セキュリティの概要やクラスタのセキュリティの強化に記載の多くの推奨事項など、セキュリティのベスト プラクティスと設定がデフォルトで有効にされ、適用されます。
ユースケースに基づく推奨リソースが必要な場合は、ユースケース別のセキュリティ リソースに進んでください。以降のセクションでは、Autopilot が適用するセキュリティ ポリシーについて説明します。
Autopilot と Kubernetes Pod のセキュリティ標準
Kubernetes プロジェクトには、Pod セキュリティ標準という名前の、次のポリシーを定義する一連のセキュリティ ガイドラインがあります。
- 特権: アクセス制限はありません。Autopilot では使用されません。
- ベースライン: 既知の権限昇格経路を防止します。これによれば、ほとんどのワークロードを大幅な変更を行わずに実行できます。
- 制限付き: 最高レベルのセキュリティです。ほとんどのワークロードに大きな変更が必要となります。
Autopilot は、ユーザビリティ改善のため、ベースライン ポリシーに修正を加えて適用します。Autopilot は、制限付きポリシーの多くの制約も適用しますが、ワークロードの大部分の実行をブロックするような制限は回避します。Autopilot は、Google が制御するアドミッション コントローラを使用して、これらの制約をクラスタレベルで適用します。制限付きのポリシーを完全に遵守するために、追加の制限を適用する必要がある場合は、必要に応じて特定の名前空間で PodSecurity アドミッション コントローラを使用できます。
Autopilot クラスタがベースライン ポリシーと制限付きポリシーを実装する方法を、次の表に示します。この表の各コントロールの説明については、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 は ProcMountType 機能フラグを設定しません。Pod securityContext で procMount が「Unmasked」に設定されている場合、GKE では自動的に「デフォルト」でオーバーライドされます。 |
||
| 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 で実行するとほとんどのワークロードが実行可能になります。 |
組み込みのセキュリティ構成
Google では、業界のベスト プラクティスと Google の専門知識に基づいて、Autopilot クラスタに組み込みのセキュリティ設定を数多く適用しています。次の表に、Autopilot によって適用されるセキュリティ構成の一部を示します。
| 構成 | 説明 |
|---|---|
| ホスト オプション |
|
| Linux 機能 | 次の Linux 機能を使用できます。 "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" 次の機能を手動で有効にすることもできます。
バージョン 1.21 より前の GKE では、 |
| 特権コンテナ | コンテナは、Google Cloud パートナーがデプロイする場合を除き、特権モードでは実行できません。特権コンテナは、kubelet の変更など、基盤となるノードへの変更を加えることができます。このアクセスにより、Pod の不正使用の影響が大きくなる可能性があります。 |
| GKE が管理する名前空間 | セキュリティ対策として、Autopilot では GKE が管理する名前空間（kube-system など）にワークロードをデプロイできません。 |
| コンテナの分離 | Autopilot は、コンテナ エスケープの脆弱性による影響を制限するため、コンテナに次の制限を適用します。 Linux 機能とカーネル セキュリティ
|
| Pod レベルのセキュリティ ポリシーの適用 | Autopilot は、PodSecurity アドミッション コントローラ、Gatekeeper、Policy Controller などの Pod レベルのセキュリティ ポリシー用の適用メカニズムをサポートしています。ただし、このページで説明する組み込みセキュリティ構成で要件がすでに満たされている場合は、これらを使用する必要はありません。 |
| ノードへの SSH 接続 | Autopilot はノードへの SSH アクセスをブロックします。ノードの健全性や、ノード上で実行されているすべての Kubernetes コンポーネントに関する処理など、ノードのすべての運用面は GKE によって処理されます。 Kubernetes の |
| ユーザーのなりすまし | GKE バージョン 1.22.4-gke.1501 以降は、すべてのユーザー定義のユーザーとグループを対象としてユーザーのなりすましに対応しています。システムのユーザーやグループ（kube-apiserver ユーザー、system:masters グループなど）は、なりすましができません。 |
| 動的アドミッション Webhook の変更 | Autopilot は、変更用 Webhook を変更して、 Autopilot は、次のリソースの 1 つ以上、あるいはそのリソースのサブリソースを指定する Webhook も拒否します。
- 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 を拒否します。 |
| 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 権限を広範囲に付与することを避け、可能な限り名前空間の管理権限の委譲を行うことをおすすめします。
Autopilot は、排他的使用のために、プロジェクトに単一テナント VM をプロビジョニングします。個々の VM 上で、Autopilot のワークロードはセキュリティが強化されたカーネルを共有し、一緒に実行されることがあります。共有カーネルは単一のセキュリティ境界を表すため、高リスクのワークロードや信頼できないワークロードなど強固な分離が必要な場合は、GKE Sandbox Pod でワークロードを実行して、多層的セキュリティを確保することをおすすめします。
ユースケースに基づくセキュリティ リソース
以降のセクションでは、ユースケースに応じて Autopilot クラスタのセキュリティを計画、実装、管理するためのリンクを示し、推奨事項について説明します。
クラスタ セキュリティを計画する
| ユースケース | 関連情報 |
|---|---|
| プラットフォームとしての GKE のセキュリティへのアプローチを理解する |
|
| 環境の強化における役割を理解する | 責任共有モデルについて確認する。 |
| セキュリティ強化とインシデント対応に関する Google の推奨事項を確認する |
|
| GKE による監査ロギングの実装方法を理解する |
|
認証と認可
Autopilot クラスタを設定した後、Kubernetes API や Google Cloud APIs などのリソースを使用するために、ユーザーとアプリケーションの認証が必要になることがあります。
| ユースケース | 関連情報 |
|---|---|
| クラスタ API サーバーでユーザーまたはアプリケーションを認証する |
|
| Google Cloud APIs とサービスに対してアプリケーションを認証する | Autopilot クラスタを使用すると、IAM サービス アカウントとして機能するように Kubernetes サービス アカウントを構成することで、GKE 用 Workload Identity 連携を使用してワークロードを Google Cloud APIs に対して安全に認証できます。手順については、GKE 用 Workload Identity 連携を使用するようにアプリケーションを構成するをご覧ください。 |
| プロジェクト レベルでアクションを認可する | プロジェクト レベルでクラスタ間のアクションを認可するには、IAM を使用します。IAM のロールと権限を使用して、特定の GKE リソースや Kubernetes API リソースへのアクセスを許可または拒否できます。手順については、IAM ポリシーを作成するをご覧ください。 |
| クラスタレベルでアクションを認可する | 特定のクラスタ内の Kubernetes API リソースに対するアクションを認可するには、組み込みの Kubernetes ロールベースのアクセス制御（RBAC）メカニズムを使用します。手順については、RBAC を使用してクラスタ内のアクションを認可するをご覧ください。 |
| 組織レベルでアクションを認可する | Google Cloud の組織のポリシー サービスを使用すると、Google Cloud 組織全体の GKE リソースに対する特定のオペレーションに制約を適用できます。手順については、カスタムの組織のポリシーを使用して GKE リソースに対するアクションを制限するをご覧ください。 |
クラスタとワークロードの強化
事前構成された Autopilot の測定の範囲を超える特殊な分離要件や強化要件がある場合は、次のリソースを検討してください。
| ユースケース | 関連情報 |
|---|---|
| クラスタ エンドポイントへの公開アクセスを制限する | Autopilot クラスタを限定公開クラスタとして作成し、クラスタ コントロール プレーンのパブリック IP アドレスを無効にします。手順については、限定公開クラスタをご覧ください。 |
| 特定のネットワークへのクラスタのアクセスを制限する | コントロール プレーン承認済みネットワークを使用して、クラスタにアクセスできる 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 セキュリティ強化ガイドを確認する。
- セキュリティに関する公開情報とリリースノートに登録する。