翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # EKS 自動モード - セキュリティ **ヒント** Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。 Amazon EKS Auto Mode は、AWS のセキュリティ管理をコントロールプレーンを超えて拡張し、ワーカーノードとコアクラスターコンポーネントを含めることで、強化されたセキュリティ機能を導入します。この包括的なセキュリティモデルは、組織が運用上のオーバーヘッドを削減しながら強力なセキュリティ体制を維持するのに役立ちます。 **責任共有モデル - EKS 自動モード** ![責任共有モデル - Amazon EKS 自動モード](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/security/SRM-AUTO.png) EKS Auto Mode の主なセキュリティ強化点は次のとおりです。 + アタックサーフェスを減らした最小コンテナ最適化 OS + EC2 マネージドインスタンスを通じてセキュリティのベストプラクティスを強制する + 必須のノードローテーションによるセキュリティパッチの自動管理 + 組み込みノードの分離とセキュリティの境界 + 最小限のアクセス許可で IAM 統合を合理化 EKS Auto Mode は、これらのセキュリティコントロールをデフォルトで適用するため、組織はセキュリティとコンプライアンスの要件を満たすと同時に、クラスターオペレーションを簡素化できます。このアプローチはdefense-in-depthの原則に沿っており、インフラストラクチャ、ノード、ワークロードレベルで複数のセキュリティコントロールレイヤーを提供します。 **重要** EKS Auto Mode は強化されたセキュリティ機能を提供しますが、組織は引き続きアプリケーションレイヤーに適切なセキュリティコントロールを実装し、クラスターで実行されているワークロードのセキュリティのベストプラクティスに従う必要があります。 ## セキュリティアーキテクチャ EKS Auto Mode は、コントロールプレーンから個々のノードまで、EKS インフラストラクチャの複数のレイヤーにセキュリティコントロールを実装します。このアーキテクチャを理解することは、EKS クラスターを効果的に管理および保護するために不可欠です。 ### コントロールプレーンのセキュリティ EKS Auto Mode の EKS コントロールプレーンは、新しいセキュリティ機能を追加しながら、従来の EKS クラスターと同じ高いセキュリティ標準を維持します。 + **エンベロープ暗号化**: すべての Kubernetes API データはエンベロープ暗号化を使用して自動的に暗号化されます。 + **KMS 統合**: Kubernetes KMS プロバイダー v2 で AWS KMS を使用し、AWS 所有のキーまたはカスタマーマネージドキー (CMK) のオプションを使用します。 + **拡張コンポーネント管理**: 自動スケーリング、ENI 管理、EBS コントローラーなどの重要なコンポーネントはクラスター外に移動され、AWS によって管理されます。 + **セキュリティコントロールと監査機能の向上**: EKS Auto Mode に必要なアクセス許可は、標準の EKS クラスターを超えて、個々のノードロールではなくクラスター IAM ロールを通じて完全に管理されます。 ### IAM 統合とアクセス管理 EKS Auto Mode は、EKS アクセスエントリと EKS Pod Identity を通じて AWS Identity and Access Management (IAM) との統合を強化します。 #### クラスターアクセス管理 EKS Auto Mode では、Cluster Access Management (CAM) API によるクラスターアクセス管理の改善が導入されています。 + による標準化された認証モード `EKS_API` + API ベースのアクセス管理によるセキュリティの強化 + アクセスエントリとアクセスポリシーを使用したアクセスコントロールの簡素化 アクセスエントリを作成して、クラスターアクセスを管理できます。 ``` aws eks create-access-entry \ --cluster-name ${EKS_CLUSTER_NAME} \ --principal-arn arn:aws:iam::${ACCOUNT_ID}:role/${IAM_ROLE_NAME} \ --type STANDARD ``` **重要** `CONFIG_MAP_AND_API` 認証モードで EKS Auto Mode クラスターを作成することは可能ですが、これは標準アプローチではなく、新しいクラスターにはデフォルトの`API`認証モードを使用することを強くお勧めします。 `API`ベースの認証は、従来の ConfigMap ベースのアプローチと比較してセキュリティを強化し、アクセス管理を簡素化します。 #### EKS Pod Identity EKS Auto Mode には Pod Identity Agent が既にデプロイされているため、ポッドに AWS IAM アクセス許可を付与する方法が合理化されています。 + OIDC プロバイダー設定なしで IAM アクセス許可管理を簡素化 + IRSA と比較した運用オーバーヘッドの削減 + セッションタグ付けと ABAC サポートによるセキュリティの強化 ``` aws eks create-pod-identity-association \ --cluster-name ${EKS_CLUSTER_NAME} \ --role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${IAM_ROLE_NAME} \ --namespace ${NAMESPACE} \ --service-account ${SERVICE_ACCOUNT_NAME} ``` **重要** Pod Identity は、IRSA と比較して強化されたセキュリティ機能とシンプルな管理を提供するため、EKS Auto Mode の IAM アクセス許可に推奨されるアプローチです。 #### ノード IAM ロール EKS Auto Mode は、EKS Auto Mode ノードが動作するために必要なアクセス許可のみ`AmazonEKSWorkerNodeMinimalPolicy`を提供する新しい を使用します。これらのアクセス許可: + 従来のノードポリシーと比較して、一連のアクセス許可を削減 + 最小特権の原則に従う + AWS によって自動的に管理および更新されます この最小限のポリシーアプローチは、ノードとそのワークロードで使用できるアクセス許可を制限することで、セキュリティ体制を改善するのに役立ちます。 ### ノードセキュリティ EKS Auto Mode では、ノードレベルでいくつかの大幅なセキュリティ強化が導入されています。 #### EC2 マネージドインスタンスのセキュリティ EKS Auto Mode ノードは、セキュリティプロパティが強化された Amazon EC2 マネージドインスタンスを使用します。 + AWS のノード運用能力を損なう可能性のあるオペレーションを防止する IAM による制限 + 設定変更でノードの交換が必要なイミュータブルなインフラストラクチャパターン + 定期的なセキュリティ更新を確保するために 21 日以内にノードを置き換える必要がある + ホップ制限が制御された IMDSv2 を使用したインスタンスメタデータへのアクセスの制限 #### オペレーティングシステムのセキュリティ オペレーティングシステムは [Bottlerocket](https://aws.amazon.com/bottlerocket/) のカスタムバリアントで、EKS Auto Mode 用に最適化されており、以下が含まれています。 + 読み取り専用ルートファイルシステム + 必須のアクセスコントロールでデフォルトで有効になっている SELinux + 一意の SELinux MCS ラベルを使用した自動ポッド分離 + SSH アクセスの無効化と不要なサービスの削除 + ノードローテーションによる自動セキュリティパッチ #### ノードコンポーネントのセキュリティ ノードコンポーネントは、セキュリティのベストプラクティスを使用して設定されます。 + 安全なデフォルトで設定された Kubelet + コンテナランタイムの強化設定 + 証明書の自動管理とローテーション + node-to-control-plane間の制限付き通信 ### ネットワークセキュリティ EKS Auto Mode は、クラスター内および外部リソースとの安全な通信を確保するために、いくつかのネットワークセキュリティ機能を実装します。 #### VPC CNI ネットワークポリシー EKS Auto Mode は、Amazon VPC CNI プラグインのネイティブ Kubernetes ネットワークポリシーのサポートを活用します。 + アップストリームの Kubernetes ネットワークポリシー API と統合 + pod-to-pod通信をきめ細かく制御できます + 入力ルールと出力ルールの両方をサポート EKS Auto Mode でネットワークポリシーのサポートを有効にするには、マ`configMap`ニフェストを使用して VPC CNI アドオンを設定する必要があります。以下がその例です。 ``` apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy: "true" ``` また、次に示すように、ネットワークポリシーのサポートがノードクラスで設定されていることを定義する必要があります。 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: example-node-class spec: networkPolicy: DefaultAllow networkPolicyEventLogs: Enabled ``` 有効にすると、ネットワークポリシーを作成してトラフィックを制御できます。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: - Ingress - Egress ``` #### 拡張 ENI 管理 EKS Auto Mode は、Elastic Network Interface (ENI) 管理のセキュリティを向上させます。 + AWS 管理の ENI アタッチメントと設定 + データトラフィックからのコントロールトラフィックの分離 + ノードに必要な権限を減らした自動 IP アドレス管理 ### ストレージセキュリティ EKS Auto Mode は、エフェメラルストレージと永続ストレージの両方に強化されたセキュリティ機能を提供します。 #### エフェメラルストレージ + エフェメラルボリュームに書き込まれたすべてのデータは自動的に暗号化されます + 業界標準の AES-256 暗号化アルゴリズムを使用 + サービスによってシームレスに処理される暗号化と復号 #### EBS ボリューム + ルートとデータ EBS ボリュームは常に暗号化されます + ボリュームは、インスタンスの終了時に削除されるように設定されます。 + 暗号化にカスタム KMS キーを指定するオプションがあります #### EFS 統合 + EFS を使用した転送中の暗号化のサポート + EFS ファイルシステムの保管時の自動暗号化 + EFS アクセスポイントとの統合によるアクセス制御の強化 **重要** EKS Auto Mode で EFS を使用する場合は、EFS ファイルシステムレベルで適切な暗号化設定が設定されていることを確認してください。EFS Auto Mode は EFS 暗号化を直接管理しないためです。 ### モニタリングとロギング EKS Auto Mode は、モニタリングとログ記録の機能を強化し、クラスターのセキュリティ体制と運用状態を可視化するのに役立ちます。 #### コントロールプレーンのログ記録 EKS Auto Mode は、標準の EKS と同じコントロールプレーンログ記録機能を維持しますが、デフォルトですべてのログを有効にしてモニタリングを強化します。 + ログは Amazon CloudWatch Logs に送信されます + デフォルトでは、EKS Auto Mode は API サーバー、監査、認証、コントローラーマネージャー、スケジューラのすべてのコントロールプレーンログを有効にします。 + EKS Auto Mode により、クラスターオペレーションとセキュリティイベントを詳細に可視化 **重要** コントロールプレーンのログ記録では、CloudWatch のログストレージに追加のコストが発生します。セキュリティニーズとコスト管理のバランスを取るために、ロギング戦略を慎重に検討してください。 #### ノードレベルのログ記録 EKS Auto Mode はノードレベルのログ記録を強化します。 + システムログは自動的に収集され、CloudWatch Logs 経由でアクセスできます + ノードログはノード終了後も保持されるため、インシデント後の分析に役立ちます。 + ノードレベルのセキュリティイベントと運用上の問題の可視性を強化 ### Amazon GuardDuty の統合 EKS Auto Mode クラスターは、脅威検出を強化するために Amazon GuardDuty とシームレスに統合されます。次の機能があります。 + コントロールプレーン監査ログの自動スキャン + ワークロードモニタリングで有効にできるランタイムモニタリング + 既存の GuardDuty の検出結果とアラートメカニズムとの統合 Amazon GuardDuty for Kubernetes 監査ログで EKS Auto Mode 保護を有効にするには、次のコマンドを実行します。 ``` aws guardduty update-detector \ --detector-id 12abc34d567e8fa901bc2d34e56789f0 \ --data-sources '{"Kubernetes":{"AuditLogs":{"Enable":true}}}' ``` #### ランタイムセキュリティのための Amazon GuardDuty 統合 Amazon GuardDuty は、EKS Auto Mode クラスターに不可欠なランタイムセキュリティモニタリングを提供し、包括的な脅威検出とセキュリティモニタリング機能を提供します。この統合は、潜在的なセキュリティ脅威と悪意のあるアクティビティをリアルタイムで特定するのに役立つため、特に重要です。 ##### EKS Auto Mode の主な GuardDuty 機能 + **ランタイムモニタリング**: + ランタイム動作の継続的なモニタリング + 悪意のあるアクティビティまたは疑わしいアクティビティの検出 + 潜在的なコンテナエスケープ試行の特定 + 異常なプロセス実行またはネットワーク接続のモニタリング + **Kubernetes 固有の脅威検出**: + 疑わしいポッドデプロイの試行の特定 + 侵害されたコンテナの検出 + 特権コンテナの起動のモニタリング + 疑わしいサービスアカウントの使用状況の特定 + **包括的な検出結果タイプ**: + ポリシー:Kubernetes/\* - セキュリティのベストプラクティスの違反を検出 + Impact:Kubernetes/\* - 影響を受ける可能性のあるリソースを特定します + Discovery:Kubernetes/\* - 偵察アクティビティを検出します + 実行:Kubernetes/\* - 疑わしい実行パターンを識別します + 永続性:Kubernetes/\* - 潜在的な永続的な脅威を検出します Amazon GuardDuty for Kubernetes 監査ログとランタイムモニタリングで EKS Auto Mode 保護を有効にするには、次のコマンドを実行します。 ``` aws guardduty update-detector \ --detector-id 12abc34d567e8fa901bc2d34e56789f0 \ --data-sources '{ "Kubernetes": { "AuditLogs": {"Enable": true}, "RuntimeMonitoring": {"Enable": true} } }' ``` **重要** GuardDuty Runtime Monitoring は EKS Auto Mode クラスターで自動的にサポートされるため、ノードレベルで追加の設定を行うことなく、セキュリティの可視性が向上します。 ##### GuardDuty の検出結果の統合 GuardDuty の検出結果は、自動応答のために他の AWS サービスと統合できます。 + **EventBridge ルール**: ``` { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "type": ["Runtime:Container/*", "Runtime:Kubernetes/*"], "severity": [4, 5, 6, 7, 8] } } ``` + **Security Hub の統合**: ``` # Enable Security Hub integration aws securityhub enable-security-hub \ --enable-default-standards \ --tags '{"Environment":"Production"}' \ --region us-west-2 ``` ##### EKS Auto Mode を使用した GuardDuty のベストプラクティス 1. **すべての検出結果タイプを有効にする**: + Kubernetes 監査ログモニタリングとランタイムモニタリングの両方を有効にする + すべての重要度レベルの検出結果を設定する 1. **自動レスポンスの実装**: + 重要度の高い検出結果の EventBridge ルールを作成する + AWS Security Hub との統合による一元的なセキュリティ管理 + 必要に応じて自動修復アクションを設定する 1. **定期的なレビューとチューニング**: + GuardDuty の検出結果を定期的に確認する + 環境に基づいて検出しきい値を調整する + 新しい検出結果タイプに基づいてレスポンス手順を更新する 1. **クロスアカウント管理**: + 一元管理に GuardDuty 管理者アカウントを使用することを検討する + 複数のアカウントで結果の集約を有効にする **警告** GuardDuty は包括的なセキュリティモニタリングを提供しますが、ネットワークポリシー、ポッドセキュリティ標準、適切な RBAC 設定などの他のセキュリティコントロールを含むdefense-in-depth戦略の一部である必要があります。 ## よくある質問 (FAQ) Q: EKS Auto Mode は、セキュリティの点で標準の EKS とどのように異なりますか? A: EKS Auto Mode は、EC2 マネージドインスタンス、自動パッチ適用、必須ノードローテーション、組み込みセキュリティコントロールを通じてセキュリティを強化します。AWS がより多くのセキュリティ面を管理できるようにすることで、強力なセキュリティ体制を維持しながら運用上のオーバーヘッドを削減します。 Q: EKS Auto Mode で既存のセキュリティツールとポリシーを引き続き使用できますか? A: はい、EKS Auto Mode はほとんどの既存のセキュリティツールやポリシーと互換性があります。ただし、一部のノードレベルのセキュリティツールでは、EKS Auto Mode ノードのマネージド型の性質上、適応が必要になる場合があります。 Q: セキュリティエージェントとモニタリングツールを EKS Auto Mode にデプロイするにはどうすればよいですか? A: EKS Auto Mode では、セキュリティエージェントとモニタリングツールは、ノード OS に直接インストールするのではなく、Kubernetes ワークロード (通常は、デフォルトですべてのノードに Pod の 1 つのインスタンスをデプロイする DaemonSets) としてデプロイする必要があります。このアプローチは、EKS Auto Mode のイミュータブルなインフラストラクチャモデルと一致しています。例: ``` apiVersion: apps/v1 kind: DaemonSet metadata: name: security-agent namespace: security spec: selector: matchLabels: app: security-agent template: metadata: labels: app: security-agent spec: containers: - name: security-agent image: security-vendor/agent:latest securityContext: privileged: false # Use specific capabilities instead of privileged mode capabilities: add: ["NET_ADMIN", "SYS_ADMIN"] ``` Q: サードパーティーのセキュリティソリューションは EKS Auto Mode と互換性がありますか? A: EKS Auto Mode をサポートするために多くの一般的なサードパーティーのセキュリティソリューションが更新されましたが、EKS Auto Mode のサポートには更新されたバージョンまたは特定のデプロイ設定が必要になる可能性があるため、セキュリティベンダーに特定のバージョンとデプロイ要件を確認することが常に推奨されます。 Q: EKS Auto Mode のセキュリティエージェントにはどのような制限がありますか? A: 主な制限事項は次のとおりです。 + ノードのオペレーティングシステムを変更するための直接アクセスがない + ノードローテーション間で永続性がない + コンテナベースのデプロイと互換性がある必要があります + ノードのイミュータビリティを尊重する必要がある + 異なる権限設定が必要になる場合があります + ノードへの永続的な変更は、 `NodePools`および `NodeClasses`リソースを通じて行う必要があります。 **注記** EKS Auto Mode では、セキュリティツールのデプロイ戦略の調整が必要になる場合がありますが、これらの変更により、クラウドネイティブのベストプラクティスに沿った、より保守的で安全な設定が得られることがよくあります。EKS Auto Mode は、管理する機能のほとんどを完全に引き継ぐことを期待しています。したがって、これらの機能に加えた手動の変更は、アクセス可能な場合、EKS Auto Mode によって上書きまたは破棄される可能性があります。 Q: EKS Auto Mode でカスタム AMIs を使用できますか? A: 現時点では、EKS Auto Mode はカスタム AMIs をサポートしていません。これは、AWS が責任共有モデルの一部としてノードのセキュリティ、パッチ適用、メンテナンスを管理するため、設計上行われます。EKS Auto Mode ノードは、AWS によって最適化および保守されている Bottlerocket の特殊なバリアントを使用します。 Q: EKS Auto Mode でノードが自動的にローテーションされる頻度はどのくらいですか? A: EKS Auto Mode のノードの最大有効期間は 21 日です。この制限の前に自動的に置き換えられるため、定期的なセキュリティ更新とパッチ適用が保証されます。 Q: トラブルシューティングのために EKS Auto Mode ノードに SSH 接続できますか? A: いいえ。EKS Auto Mode では直接 SSH アクセスを使用できません。代わりに、NodeDiagnostic Custom Resource Definition (CRD) を使用してシステムログを収集し、情報をデバッグできます。 Q: ネットワークポリシーのサポートは EKS Auto Mode でデフォルトで有効になっていますか? A: 現時点では、ネットワークポリシーのサポートは VPC CNI アドオン設定を使用して明示的に有効にする必要があります。有効にすると、標準の Kubernetes ネットワークポリシーを使用できます。 Q: EKS Auto Mode で IRSA または Pod Identity を使用する必要がありますか? A: どちらもサポートされていますが、EKS Auto Mode では、Pod Identity に Pod Identity Security エージェントアドオンが既に含まれており、セキュリティ機能の強化と管理の簡素化が推奨されています。 Q: EKS Auto Mode で aws-auth ConfigMap を引き続き使用できますか? A: `aws-auth` ConfigMap は非推奨の機能です。セキュリティを強化し、アクセス管理を簡素化するために、API ベースの認証のデフォルトのアプローチを使用することをお勧めします。 Q: EKS Auto Mode でセキュリティイベントをモニタリングするにはどうすればよいですか? A: EKS Auto Mode は、GuardDuty、CloudWatch、CloudTrail などの複数のモニタリングソリューションと統合されています。GuardDuty は、EKS ワークロード専用の拡張ランタイムセキュリティモニタリングを提供します。 Q: EKS Auto Mode ノードからログを収集するにはどうすればよいですか? A: NodeDiagnostic CRD を使用します。これにより、S3 バケットにログが自動的にアップロードされます。CloudWatch Container Insights と AWS Distro for OpenTelemetry を使用することもできます。 **注記** このよくある質問セクションは、新機能が EKS Auto Mode に追加され、お客様からよくある質問が寄せられると、定期的に更新されます。