セキュリティの概要

Google Kubernetes Engine では、さまざまな方法でワークロードを保護できます。Google Kubernetes Engine でワークロードを保護するには、コンテナ イメージのコンテンツ、コンテナのランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなど、何層ものスタックが必要です。

クラスタとワークロードの保護には、階層的なアプローチをおすすめします。ユーザーとアプリケーションのアクセスレベルは、最小権限の原則に従って決定します。ワークロードのデプロイとメンテナンスを安全に行うためには柔軟性とセキュリティのバランスを適切に取る必要がありますが、このバランスは階層によって異なります。たとえば、一部のセキュリティ設定は特定の種類のアプリケーションにとって制限が多すぎたり、大幅にリファクタリングしないと使用目的に適合しなかったりする場合があります。

このドキュメントでは、インフラストラクチャの各レイヤの概要と、ニーズに合わせて最適なセキュリティ機能を構成する方法について説明します。

認証と承認

Kubernetes は次の 2 種類の認証をサポートしています。

  1. ユーザー アカウントは、Kubernetes で認識はされますが、Kubernetes では管理されないアカウントです。このため、たとえば、kubectl を使用した作成や削除はできません。
  2. サービス アカウントは、Kubernetes によって作成と管理は行われますが、Kubernetes によって作成されたエンティティ(ポッドなど)でしか使用できないアカウントです。

Google Kubernetes Engine クラスタでは、Kubernetes ユーザー アカウントは Google Cloud で管理され、次の 2 種類のいずれかになります。

  1. Google アカウント
  2. Google Cloud サービス アカウント

認証後、それらの ID に Kubernetes リソースの作成、読み取り、更新、削除を許可する必要があります。

Kubernetes サービス アカウントと Google Cloud サービス アカウントは、名前は同じでも異なるエンティティです。Kubernetes サービス アカウントは、クラスタの一部として定義され、通常はそのクラスタ内で使用されます。それに対し、Google Cloud サービス アカウントは Google Cloud プロジェクトの一部であり、クラスタ内における権限だけでなく、Google Cloud プロジェクトのクラスタ自体に対する権限も簡単に付与できます。また、Cloud Identity and Access Management(Cloud IAM)を使用して、あらゆる Google Cloud リソースに対する権限も付与できます。このため、Google Cloud サービス アカウントは Kubernetes サービス アカウントよりも強力です。最小限の権限のセキュリティ原則に従うために、Google Cloud サービス アカウントの使用はその機能が必要な場合のみにする必要があります。

クラスタレベルや Kubernetes 名前空間内で Kubernetes リソースへのアクセス権限を詳細に構成するには、役割ベースのアクセス制御(RBAC)を使用します。RBAC では、詳細なポリシーを作成して、ユーザーとサービス アカウントがアクセス可能なオペレーションとリソースを定義できます。RBAC を使用すると、Google アカウント、Google Cloud サービス アカウント、Kubernetes サービス アカウントへのアクセスを制御できます。Google Kubernetes Engine の認証と承認の戦略をさらに簡略化、合理化するには、従来の属性ベースのアクセス制御が無効で Kubernetes RBAC と Cloud IAM がソースになっていることを確認する必要があります。

詳細については、以下をご覧ください。

コントロール プレーンのセキュリティ

Google Kubernetes Engine では、Kubernetes のマスター コンポーネントの管理とメンテナンスは Google が行います。マスター コンポーネントは、API サーバー、スケジューラ、コントローラ マネージャー、Kubernetes 構成が保持されている etcd データベースなどの Kubernetes コントロール プレーンを実行するソフトウェアをホストします。

デフォルトでは、マスター コンポーネントはパブリック IP アドレスを使用します。マスター承認済みのネットワーク限定公開クラスタを使用することで Kubernetes API サーバーを保護できます。限定公開のクラスタでは、マスターに限定公開の IP アドレスを割り当て、公開 IP アドレスからのアクセスを遮断できます。

Cloud IAM を ID プロバイダとして使用すると、Google Kubernetes Engine でクラスタ認証を処理できます。ただし、従来のユーザー名とパスワードによる認証は、Google Kubernetes Engine ではデフォルトで有効になっています。認証のセキュリティを強化するには、MasterAuth 構成に空のユーザー名とパスワードを設定して基本認証が無効化されていることを確認する必要があります。同じ構成でクライアント証明書を無効にすると、クラスタへのアクセスを遮断する場合の考慮事項を 1 つ減らすことができます。

定期的に認証情報をローテーションすると、Kubernetes マスターの保護を強化できます。認証情報のローテーションを開始すると、SSL 証明書とクラスタ認証局がローテーションされます。これは Google Kubernetes Engine によって自動的に行われ、マスターの IP アドレスが確実にローテーションされます。

詳細については、以下をご覧ください。

ノードのセキュリティ

Google Kubernetes Engine は、Google Cloud プロジェクトで実行されている Compute Engine インスタンスにワークロードをデプロイします。これらのインスタンスは、ノードとして Google Kubernetes Engine クラスタに接続されています。次のセクションでは、Google Cloud で使用可能なノードレベルのセキュリティ機能の使用方法を説明します。

コンテナ最適化 OS

Google Kubernetes Engine ノードのデフォルトでは、Kubernetes とそのコンポーネントを実行するオペレーティング システムとして Google のコンテナ用に最適化された OS が使用されています。Container-Optimized OS には Google Kubernetes Engine クラスタのセキュリティを強化する高度な機能が複数実装されています。その例を次に示します。

  • ファイアウォールの遮断
  • 読み取り専用ファイルシステム(可能な場合)
  • 制限付きユーザー アカウントと root ログインの無効化

ノードのアップグレード

OS には定期的にパッチを適用することをおすすめします。コンテナのランタイム、Kubernetes 自体、ノードのオペレーティング システムのセキュリティに問題が発生すると、ノードの緊急アップグレードが必要となる場合があります。ノードをアップグレードすると、ノードのソフトウェアは最新バージョンになります。

クラスタ内のノードは手動でアップグレードできますが、Google Kubernetes Engine では自動アップグレードを有効にすることもできます。

ノードを信頼できないワークロードから保護する

不明または信頼できないワークロードを実行するクラスタでは、ポッド内で実行される信頼できないワークロードからノードのオペレーティング システムを保護することをおすすめします。

たとえば、Software-as-a-Service(SaaS)プロバイダなどのマルチテナント クラスタは、ユーザーから送信された不明なコードを実行することも珍しくありません。セキュリティ調査も、ワークロードに対してノードのデフォルトよりも強力な隔離が必要になる可能性があるアプリケーションの 1 つです。

GKE Sandbox をクラスタで有効にすると、信頼できないワークロードをノード上のサンドボックス内に隔離できます。GKE Sandbox は、オープンソースのプロジェクトである gVisor を使用して構築されています。

インスタンス メタデータの保護

Google Kubernetes Engine ノードは Compute Engine インスタンスとして実行されるため、デフォルトでインスタンス メタデータへのアクセス権限を持ちます。インスタンス メタデータからは、ブートストラップや Kubernetes マスターノードへの接続に使用される認証情報と構成がノードに提供されます。ただしノード上で実行されているポッドでは、ノードのサービス アカウント キーなどの機密データが含まれるこの情報は必ずしも必要ではありません。従来の API を無効化しメタデータ隠蔽を使用すると、インスタンスの機密メタデータへのパスを遮断できます。メタデータ隠蔽により kube-env などのフィールドに対するリクエストがフィルタリングされ、クラスタ内で実行されているポッドは機密データにアクセスできなくなります。

ネットワーク セキュリティ

Google Kubernetes Engine で実行されているワークロードの大部分は、クラスタの内部または外部で実行されている他のサービスと通信する必要があります。クラスタやそのポッドを流れるトラフィックを制御する方法は、複数あります。

ポッド間の通信を制限する

デフォルトでは、クラスタ内のすべてのポッドはポッドの IP アドレスを使用してネットワークにアクセスできます。同様に、デフォルトでは、クラスタがデプロイされている VPC 内の任意のアクセス可能なアドレスへの送信接続が送信トラフィックにより許可されます。

クラスタ管理者とユーザーは、ネットワーク ポリシーを使用すると、名前空間内のポッドへの受信接続やそのポッドからの送信接続を遮断できます。デフォルトでは、ネットワーク ポリシーが定義されていない場合、ポッドへのすべての入力トラフィックとポッドからのすべての出力トラフィックが許可されます。ネットワーク ポリシーを使用すると、タグを使用してポッドを流れるトラフィックを定義できます。

名前空間でネットワーク ポリシーが適用されると、ポッドからのトラフィックとポッドへのトラフィックのうち、構成されたラベルと一致しないものはすべてドロップされます。クラスタや名前空間を作成するときにすべてのポッドで受信トラフィックと送信トラフィックをデフォルトで拒否するように設定すると、クラスタに新しいワークロードを追加した場合に明示的にトラフィックを承認することが必要になります。

詳細については、以下をご覧ください。

負荷分散されたトラフィックのフィルタリング

Kubernetes ポッドでネットワーク ロードバランサを使用して負荷分散を行うには、タイプ LoadBalancer がポッドのラベルと一致するサービスを作成する必要があります。サービスを作成すると外部接続用 IP が取得され、Kubernetes ポッドのポートにマッピングされます。承認済みのトラフィックのフィルタリングは、IP アドレスに基づいて kube-proxy がノードレベルで行います。

このフィルタリングは、Service オブジェクトの loadBalancerSourceRanges 構成で指定します。この構成パラメータでは、サービスへのアクセスを許可する CIDR 範囲のリストを指定できます。loadBalancerSourceRanges を構成しない場合は、すべてのアドレスが外部 IP 経由でサービスにアクセスできます。

サービスへのアクセスが不要な場合は、内部ロードバランサの使用を検討してください。VPC 内部からのトラフィックをフィルタリングする必要がある場合は、loadBalancerSourceRanges も内部ロードバランサに適用されます。

詳細については、以下をご覧ください。

ワークロードの保護

Kubernetes では、コンテナベースのワークロードのプロビジョニング、スケーリング、更新を迅速に行うことができます。このセクションでは、管理者やユーザーが実行中のコンテナを制御し、同じクラスタ内の他のコンテナ、コンテナが実行されるノード、ユーザーのプロジェクトで有効になっている Google Cloud サービスに対するそのコンテナの影響範囲を制限する方法について説明します。

ポッドコンテナのプロセス権限を制限する

コンテナ化されたプロセスの権限を制限することは、クラスタの全体的なセキュリティにとって重要です。Google Kubernetes Engine では、ポッドとコンテナの両方で securityContext を使用してセキュリティ関連のオプションを設定できます。この設定では、次のようにプロセスのセキュリティ設定を変更できます。

  • 実行するユーザーとグループ
  • 利用可能な Linux 機能
  • 権限を昇格させる能力

これらの設定をポッドやコンテナではなくクラスタレベルで変更するには、PodSecurityPolicy を実装する必要があります。クラスタ管理者が PodSecurityPolicy を使用すると、ここで定義された最小限のベースライン ポリシーにクラスタ内のすべてのポッドを準拠させることができます。

Google Kubernetes Engine ノードでは、Container-Optimized OS と Ubuntu のどちらのオペレーティング システムが使用されている場合でも、Kubernetes で起動されたすべてのコンテナにデフォルトの Docker AppArmor セキュリティ ポリシーが適用されます。プロファイルのテンプレートは GitHub で確認できます。特に、次のプロファイルではコンテナに対する以下の機能が拒否されます。

  • /proc/ 内のファイルに直接書き込む
  • プロセス ID ディレクトリ(/proc/<number>)内に存在しないファイルに書き込む
  • /proc/sys 内に存在する /proc/sys/kernel/shm* 以外のファイルに書き込む
  • ファイル システムをマウントする

詳細については、以下をご覧ください。

ポッドに Google Cloud リソースへのアクセス権限を付与する

コンテナとポッドは、Google Cloud 内の他のリソースへのアクセスを必要とする場合があります。このための方法が 3 つあります。

ポッドに Google Cloud リソースへのアクセス権限を付与する最も簡単で安全な方法は、Workload Identity です。Workload Identity を使用すると、Kubernetes サービス アカウントを Google Cloud サービス アカウントとして実行できます。Kubernetes サービス アカウントとして実行するポッドには、Google Cloud サービス アカウントの権限が与えられます。

Workload Identity は GKE Sandbox で使用できます。

ノードサービス アカウント

ポッドは、メタデータにある Kubernetes クラスタのサービス アカウントの認証情報を使用して Google Cloud に対する認証を行うこともできます。ただし、これらの認証情報にアクセスできるのは、クラスタ内で実行中のポッドです。クラスタ内で実行中のすべてのポッドが必要とする最小限の Cloud IAM 役割を持つカスタム サービス アカウントを作成して構成します。

GKE Sandbox ではメタデータ サーバーへのアクセスがブロックされるため、この方法には GKE Sandbox との互換性はありません。

サービス アカウント JSON キー

Google Cloud リソースに対する認証情報をアプリケーションに付与する 3 番目の方法では、サービス アカウント キーを手動で使用します。この方法は、アカウントキーを安全に管理するのが難しいため、強く非推奨とされます。

アプリケーション専用の GCP サービス アカウントを使用して認証情報を付与して、アプリケーションに付与する権限を必要最小限に抑えてください。各サービス アカウントには、ペアに設定されたアプリケーションが正常に動作するために必要な Cloud IAM 役割だけが割り当てられます。サービス アカウントをアプリケーション専用にしておくと、不正使用が発生した場合に、アクセス権限を簡単に取り消して他のアプリケーションへの影響を防止できます。サービス アカウントに適切な Cloud IAM 役割を割り当てると、Kubernetes シークレットを使用して JSON サービス アカウント キーを作成し、ポッドにマウントできます。

Binary Authorization を使用する

Binary Authorization は Google Cloud 上のサービスであり、クラウド内で実行されるアプリケーションにソフトウェア サプライ チェーン セキュリティを提供します。Binary Authorization は、Container Registry または他のコンテナ イメージ レジストリから GKE にデプロイするイメージに対して機能します。Binary Authorization を使用すると、アプリケーションを本番環境にデプロイする前に、ソフトウェアの品質と整合性を保護するための内部プロセスを正常かつ確実に完了できます。

Binary Authorization を有効にしたクラスタを作成する方法については、Binary Authorization ドキュメントクラスタの作成をご覧ください。

監査ロギング

監査ロギングを使用すると、管理者が Google Kubernetes Engine 環境で発生したイベントの保持、クエリ、処理、アラート生成を行うことができます。記録された情報は、フォレンジック分析、リアルタイムでの通知、Google Kubernetes Engine クラスタを使用しているユーザーとその使用方法のカタログ化に利用できます。

デフォルトでは、Google Kubernetes Engine では管理アクティビティ ログが記録されます。また、検査対象のオペレーションの種類によってはデータアクセス イベントを記録することもできます。

詳細については、以下をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント