セキュリティ

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

概要

Anthos clusters on AWS は、コンテナ イメージのコンテンツ、コンテナ ランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなどのワークロードを保護することを目的としたいくつかの機能を備えています。

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

責任の共有

Anthos clusters on AWS を使用すると、クラスタの特定の責任を担うことに同意したことになります。詳しくは、Anthos クラスタの責任の共有をご覧ください。

認証と認可

次のいずれかの方法を使用して、Anthos clusters on AWS ユーザー クラスタの認証を行います。

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

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

Encryption

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

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

Kubernetes Secret

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

HashiCorp Vault

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

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

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

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

Anthos clusters 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 として保存されます。

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

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

  • API サーバー、コントロール プレーン、ノードに対して、Anthos clusters on AWS では、アップグレードのたびに TLS 証明書をローテーションします。
  • 手動でセキュリティ認証情報をローテーションすることもできます。

ノードのセキュリティ

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

Ubuntu

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

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

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

ノードのアップグレード

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

ワークロードの保護

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

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

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

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

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

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

次のステップ