セキュリティの概要

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

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

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

認証と承認

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

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

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

  1. Google アカウント
  2. Google Cloud Platform(GCP)サービス アカウント

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

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

クラスタレベルや Kubernetes 名前空間内で Kubernetes リソースへのアクセス権限を細かく構成するには、役割ベースのアクセス制御(RBAC)を使用します。RBAC では、詳細なポリシーを作成して、ユーザーとサービス アカウントがアクセス可能なオペレーションとリソースを定義できます。RBAC を使用すると、Google アカウント、GCP サービス アカウント、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 は、GCP プロジェクトで実行されている Compute Engine インスタンスにワークロードをデプロイします。これらのインスタンスは、ノードとして Google Kubernetes Engine クラスタに接続されています。次のセクションでは、GCP で使用可能なノードレベルのセキュリティ機能の使用方法を説明します。

Container-Optimized OS

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

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

ノードのアップグレード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ワークロードの保護

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

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

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

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

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

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

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

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

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

コンテナとポッドは、GCP 内の他のリソースへのアクセスを必要とする場合があります。アプリケーションが GCP リソースの認証情報にアクセスする方法の 1 つに、メタデータから Kubernetes クラスタのサービス アカウントの認証情報を使用する方法があります。ただし、これらの認証情報にはクラスタ上で実行されているすべてのポッドからアクセスできます。クラスタ用のカスタム サービス アカウントを作成し、クラスタ内で実行されているすべてのポッドに適用する最小限の IAM 役割を適用するように構成する必要があります。

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

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

Binary Authorization を使用する

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

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

監査ロギング

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

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

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

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

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

Kubernetes Engine のドキュメント