データ暗号化とシークレット管理 - Amazon EKS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

データ暗号化とシークレット管理

保管中の暗号化

Kubernetes で使用できる AWS ネイティブストレージには、EBSEFSFSx for Lustre の 3 つの異なるオプションがあります。3 つのオプションはすべて、サービスマネージドキーまたはカスタマーマスターキー (CMK) を使用して保管時の暗号化を行います。EBS の場合は、ツリー内ストレージドライバーまたは EBS CSI ドライバーを使用できます。どちらも、ボリュームを暗号化し、CMK を提供するためのパラメータが含まれています。EFS の場合、EFS CSI ドライバーを使用できますが、EBS とは異なり、EFS CSI ドライバーは動的プロビジョニングをサポートしていません。EKS で EFS を使用する場合は、PV を作成する前に、ファイルシステムの保管時の暗号化をプロビジョニングして設定する必要があります。EFS ファイルの暗号化の詳細については、「保管中のデータの暗号化」を参照してください。保管時の暗号化の提供に加えて、EFS と FSx for Lustre には、転送中のデータを暗号化するためのオプションが含まれています。FSx for Lustre はデフォルトでこれを行います。EFS の場合、次の例のように tlsパラメータを PV mountOptionsの に追加することで、トランスポート暗号化を追加できます。

apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: efs-sc mountOptions: - tls csi: driver: efs.csi.aws.com volumeHandle: <file_system_id>

FSx CSI ドライバーは、Lustre ファイルシステムの動的プロビジョニングをサポートします。デフォルトではサービスマネージドキーでデータを暗号化しますが、次の例のように独自の CMK を指定するオプションがあります。

kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: fsx-sc provisioner: fsx.csi.aws.com parameters: subnetId: subnet-056da83524edbe641 securityGroupIds: sg-086f61ea73388fb6b deploymentType: PERSISTENT_1 kmsKeyId: <kms_arn>
重要

2020 年 5 月 28 日現在、EKS Fargate ポッドのエフェメラルボリュームに書き込まれるすべてのデータは、業界標準の AES-256 暗号化アルゴリズムを使用してデフォルトで暗号化されています。暗号化と復号は サービスによってシームレスに処理されるため、アプリケーションに変更を加える必要はありません。

保管中のデータを暗号化する

保管中のデータの暗号化はベストプラクティスと見なされます。暗号化が必要かどうか不明な場合は、データを暗号化します。

CMKsを定期的にローテーションする

CMKs を自動的にローテーションするように KMS を設定します。これにより、年 1 回キーがローテーションされ、古いキーは無期限に保存されるため、データは復号できます。詳細については、「カスタマーマスターキーの更新」を参照してください。

EFS アクセスポイントを使用して共有データセットへのアクセスを簡素化する

異なる POSIX ファイルアクセス許可を持つ共有データセットがある場合、または異なるマウントポイントを作成して共有ファイルシステムの一部へのアクセスを制限する場合は、EFS アクセスポイントの使用を検討してください。アクセスポイントの操作の詳細については、https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html を参照してください。現在、アクセスポイント (AP) を使用する場合は、PV の volumeHandleパラメータで AP を参照する必要があります。

重要

2021 年 3 月 23 日現在、EFS CSI ドライバーは EFS アクセスポイントの動的プロビジョニングをサポートしています。アクセスポイントはEFS ファイルシステムへのアプリケーション固有のエントリポイントであり、複数のポッド間でファイルシステムを簡単に共有できます。各 EFS ファイルシステムは、最大 120 PVs を持つことができます。詳細については、「Amazon EFS CSI 動的プロビジョニングの紹介」を参照してください。

シークレットの管理

Kubernetes シークレットは、ユーザー証明書、パスワード、API キーなどの機密情報を保存するために使用されます。これらは、base64 でエンコードされた文字列として etcd に保持されます。EKS では、 etcd ノードの EBS ボリュームは EBS 暗号化で暗号化されます。ポッドは、 のシークレットを参照することで、Kubernetes シークレットオブジェクトを取得できますpodSpec。これらのシークレットは、環境変数にマッピングすることも、ボリュームとしてマウントすることもできます。シークレットの作成の詳細については、https://kubernetes.io/docs/concepts/configuration/secret/ を参照してください。

警告

特定の名前空間内のシークレットは、シークレットの名前空間内のすべてのポッドで参照できます。

警告

ノードオーソライザーを使用すると、Kubelet はノードにマウントされたすべてのシークレットを読み取ることができます。

Kubernetes シークレットのエンベロープ暗号化に AWS KMS を使用する

これにより、一意のデータ暗号化キー (DEK) を使用してシークレットを暗号化できます。その後、DEK は AWS KMS のキー暗号化キー (KEK) を使用して暗号化され、定期的なスケジュールで自動的にローテーションできます。Kubernetes 用 KMS プラグインを使用すると、すべての Kubernetes シークレットはプレーンテキストではなく暗号化テキストの etcd に保存され、Kubernetes API サーバーによってのみ復号できます。詳細については、「EKS 暗号化プロバイダーのサポートを使用した多層防御」を参照してください。

Kubernetes シークレットの使用を監査する

EKS で、監査ログ記録を有効にし、シークレットが使用されたときに警告する CloudWatch メトリクスフィルターとアラームを作成します (オプション)。以下は、Kubernetes 監査ログ のメトリクスフィルターの例です{($.verb="get") && ($.objectRef.resource="secret")}。CloudWatch Log Insights では、次のクエリを使用することもできます。

fields @timestamp, @message | sort @timestamp desc | limit 100 | stats count(*) by objectRef.name as secret | filter verb="get" and objectRef.resource="secrets"

上記のクエリには、特定の期間内にシークレットにアクセスされた回数が表示されます。

fields @timestamp, @message | sort @timestamp desc | limit 100 | filter verb="get" and objectRef.resource="secrets" | display objectRef.namespace, objectRef.name, user.username, responseStatus.code

このクエリは、シークレットにアクセスしようとしたユーザーの名前空間とユーザー名、およびレスポンスコードとともにシークレットを表示します。

シークレットを定期的にローテーションする

Kubernetes はシークレットを自動的にローテーションしません。シークレットを更新する必要がある場合は、Vault や AWS Secrets Manager などの外部シークレットストアの使用を検討してください。

異なるアプリケーションからシークレットを分離する方法として個別の名前空間を使用する

名前空間内のアプリケーション間で共有できないシークレットがある場合は、それらのアプリケーション用に別の名前空間を作成します。

環境変数の代わりにボリュームマウントを使用する

環境変数の値は、意図せずにログに表示される可能性があります。ボリュームとしてマウントされたシークレットは tmpfs ボリューム (RAM ベースのファイルシステム) としてインスタンス化され、ポッドが削除されるとノードから自動的に削除されます。

外部シークレットプロバイダーを使用する

Kubernetes シークレットの使用には、AWS Secrets Manager や Hashicorp のボールトなど、いくつかの実行可能な選択肢があります。これらのサービスは、きめ細かなアクセスコントロール、強力な暗号化、Kubernetes Secrets では利用できないシークレットの自動ローテーションなどの機能を提供します。Bitnami のシールされたシークレットは、非対称暗号化を使用して「シールされたシークレット」を作成するもう 1 つのアプローチです。パブリックキーはシークレットを暗号化するために使用されますが、シークレットの復号に使用されるプライベートキーはクラスター内に保持されるため、Git などのソース管理システムにシールされたシークレットを安全に保存できます。詳細については、「シールされたシークレットを使用した Kubernetes でのシークレットデプロイの管理」を参照してください。

外部シークレットストアの使用が増えるにつれて、 はそれらを Kubernetes と統合する必要があります。Secret Store CSI ドライバーは、CSI ドライバーモデルを使用して外部シークレットストアからシークレットを取得するコミュニティプロジェクトです。現在、ドライバーは AWS Secrets Manager、Azure、Vault、および GCP をサポートしています。AWS プロバイダーは、AWS Secrets Manager AWS Parameter Store の両方をサポートしています。また、有効期限が切れたときにシークレットをローテーションするように設定し、AWS Secrets Manager シークレットを Kubernetes シークレットに同期することもできます。シークレットの同期は、シークレットをボリュームから読み取るのではなく、環境変数として参照する必要がある場合に役立ちます。

注記

シークレットストア CSI ドライバーがシークレットを取得する必要がある場合、シークレットを参照するポッドに割り当てられた IRSA ロールを引き受けます。このオペレーションのコードは、こちらにあります。

AWS Secrets & Configuration Provider (ASCP) の詳細については、次のリソースを参照してください。

external-secrets は、Kubernetes で外部シークレットストアを使用するもう 1 つの方法です。CSI ドライバーと同様に、外部シークレットは AWS Secrets Manager など、さまざまなバックエンドに対して機能します。違いは、外部シークレットストアからシークレットを取得するのではなく、外部シークレットはこれらのバックエンドからシークレットとして Kubernetes にシークレットをコピーすることです。これにより、任意のシークレットストアを使用してシークレットを管理し、Kubernetes ネイティブの方法でシークレットとやり取りできます。

ツールとリソース