セキュリティ

このページでは、GKE on AWS のインフラストラクチャの各レイヤに含まれるセキュリティ機能と、ニーズに合わせてセキュリティ機能を構成する方法について説明します。

概要

GKE on AWS には、コンテナ イメージのコンテンツ、コンテナのランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなどのワークロードを保護するいくつもの機能があります。

クラスタとワークロードの保護には、階層的なアプローチをおすすめします。ユーザーとワークロードに付与するアクセスレベルに対して最小権限の原則を適用できます。柔軟性とセキュリティの適切なレベルについてトレードオフを見極める必要があります。

責任の共有

GKE on AWS を使用すると、ご自身のクラスタに対して特定の責任を負うことに同意したものと見なされます。詳細については、GKE クラスタの責任の共有をご覧ください。

認証と認可

次のいずれかの方法で GKE on AWS ユーザー クラスタに対する認証を行います。

クラスタレベルまたは Kubernetes Namespace 内で Kubernetes リソースへのアクセス権限を詳細に構成するには、Kubernetes のロールベースのアクセス制御（RBAC）を使用します。RBAC を使用すると、詳細なポリシーを作成して、ユーザーとサービス アカウントのアクセスを許可するオペレーションとリソースを定義できます。RBAC では、指定された任意の検証済み ID に対するアクセスを制御できます。

Kubernetes Engine の認証と認可の戦略をさらに簡素化、合理化するには、GKE on AWS で、以前の属性ベースのアクセス制御（ABAC）を無効にします。

暗号化

GKE on AWS はデフォルトで、AWS Key Management Service（KMS）により、etcd にある保存データ、EBS ボリューム、Kubernetes Secret、コントロール プレーン コンポーネントを暗号化します。

ユーザー クラスタ内の機密データを暗号化するには、次のいずれかを使用します。

Kubernetes Secret

Kubernetes の Secret リソースは、パスワード、OAuth トークン、SSH 認証鍵などの機密性の高いデータをクラスタに格納します。Secret への機密データの保存は、平文の ConfigMaps や Pod 仕様への保存よりも安全です。Secret を使用すると、機密データの使用方法を制御し、権限のないユーザーにデータが公開されるリスクを軽減できます。

HashiCorp Vault

GKE on AWS は、HashiCorp Vault を使用して、ユーザー クラスタの Secret を保護します。詳細については、GKE on AWS での HashiCorp Vault の使用をご覧ください。

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

コントロール プレーン コンポーネントには、管理サービスとユーザー クラスタの Kubernetes API サーバー、スケジューラ、コントローラ、etcd データベースが含まれます。GKE on AWS では、ローカルの管理者がコントロール プレーンのコンポーネントを管理します。

GKE on AWS では、コントロール プレーン コンポーネントは AWS 上で実行されます。AWS のセキュリティ グループとネットワーク ACL を使用すると、AWS の API サーバーで GKE を保護できます。

GKE on AWS の通信はすべて、Transport Layer Security（TLS）チャネルを介して行われ、次の認証局（CA）によって管理されます。

  • etcd CA は、API サーバーから etcd レプリカへの通信と、etcd レプリカ間のトラフィックを保護します。この CA は自己署名です。
  • ユーザー クラスタ CA は、API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラ、スケジューラ）間の通信を保護します。この CA は KMS で暗号化されています。
  • 管理サービス CA は AWS KMS で暗号化されています。anthos-gke init を実行すると作成され、Terraform ワークスペースに保存されます。terraform apply を使用して管理サービスを作成すると、CA 鍵は AWS EC2 のユーザーデータとして渡され、クラスタの起動時に AWS KMS によって復号されます。

管理サービスの場合、コントロール プレーンの鍵はコントロール プレーン [nodes]{:.external} に格納されます。ユーザー クラスタの場合、鍵は管理サービスのコントロール プレーンに Kubernetes Secret として保存されます。

GKE on AWS のクラスタ認証は、証明書とサービス アカウント署名なしトークンによって処理されます。管理者は、管理者証明書（初期ロール バインディングの作成や緊急時に使用）を使用してコントロール プレーンに対して認証します。

証明書のローテーションは次のように行われます。

ノードのセキュリティ

GKE on AWS では、AWS EC2 インスタンスのノードプールにワークロードをデプロイします。以降のセクションでは、GKE on AWS でノードレベルのセキュリティ機能を使用する方法について説明します。

Ubuntu

GKE on AWS は、Kubernetes コントロール プレーンとノードを実行するオペレーティング システムとして、最適化されたバージョンの Ubuntu を使用します。Ubuntu には最新のセキュリティ機能が豊富に用意されており、GKE on AWS では次のようなセキュリティ強化機能が実装されています。

  • 最適化されたパッケージのセット。
  • Google Cloud 向けにカスタマイズされた Linux カーネル。
  • 制限付きユーザー アカウントと root ログインの無効化

Ubuntu には、次のような別のセキュリティ ガイドも用意されています。

ノードのアップグレード

定期的にノードをアップグレードする必要があります。コンテナのランタイム、Kubernetes そのもの、ノードのオペレーティング システムのセキュリティに問題が発生すると、ノードの緊急アップグレードが必要となる場合があります。ユーザー クラスタをアップグレードすると、各ノードのソフトウェアが最新バージョンになります。さらに、ノードをアップグレードすると、暗号化の認証情報がローテーションされます。

ワークロードの保護

Kubernetes では、コンテナベースのワークロードのプロビジョニング、スケーリング、更新を迅速に行うことができます。このセクションでは、クラスタと Google Cloud サービスでコンテナを実行する場合の副作用を制限する方法について説明します。

Pod コンテナのプロセス権限を制限する

コンテナ化されたプロセスの権限を制限することは、クラスタのセキュリティにとって重要です。セキュリティ関連のオプションは、Pod とコンテナのセキュリティ コンテキストで設定できます。これらの設定により、次のようなプロセスのセキュリティ設定を変更できます。

  • プロセスを実行しているユーザーとグループ。
  • 利用可能な Linux 機能
  • 権限昇格

デフォルトの GKE on AWS ノードのオペレーティング システムである Ubuntu は、Kubernetes が起動したすべてのコンテナにデフォルトの Docker AppArmor セキュリティ ポリシーを適用します。プロファイルのテンプレートは GitHub で確認できます。特に、次のプロファイルではコンテナに対する以下の機能が拒否されます。

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

次のステップ