翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # インフラストラクチャ (ホスト) の保護 コンテナイメージを保護することは重要ですが、コンテナイメージを実行するインフラストラクチャを保護することも同様に重要です。このセクションでは、ホストに対して直接起動される攻撃によるリスクを軽減するさまざまな方法について説明します。これらのガイドラインは、[「ランタイムセキュリティ](runtime-security.md)」セクションで説明されているガイドラインと組み合わせて使用する必要があります。 ## 推奨事項 ### コンテナの実行に最適化された OS を使用する Linux コンテナの実行用に設計された AWS の専用 OS である Flatcar Linux、Project Atomic、RancherOS、[Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/) の使用を検討してください。これには、攻撃対象領域の削減、起動時に検証されるディスクイメージ、SELinux を使用した強制的なアクセス許可の境界が含まれます。 または、Kubernetes ワーカーノードに [EKS 最適化 AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-amis.html) を使用します。EKS 最適化 AMI は定期的にリリースされ、コンテナ化されたワークロードを実行するために必要な最小限の OS パッケージとバイナリのセットが含まれています。 Hashicorp Packer を使用して Red Hat Enterprise Linux で実行されているカスタム [Amazon EKS AMI を構築するために使用できるサンプル設定スクリプトについては、Amazon EKS AMI RHEL ビルド仕様](https://github.com/aws-samples/amazon-eks-ami-rhel)を参照してください。このスクリプトをさらに活用して、STIG 準拠の EKS カスタム AMIs を構築できます。 ### ワーカーノード OS を最新の状態に保つ Bottlerocket などのコンテナ最適化ホスト OS を使用するか、EKS 最適化 AMIs などの Amazon マシンイメージを使用するかにかかわらず、これらのホスト OS イメージを最新のセキュリティパッチで最新の状態に保つことをお勧めします。 EKS 最適化 AMIs の場合、[CHANGELOG](https://github.com/awslabs/amazon-eks-ami/blob/master/CHANGELOG.md) および/または[リリースノートチャネル](https://github.com/awslabs/amazon-eks-ami/releases)を定期的にチェックし、更新されたワーカーノードイメージのクラスターへのロールアウトを自動化します。 ### インフラストラクチャをイミュータブルとして扱い、ワーカーノードの交換を自動化する インプレースアップグレードを実行するのではなく、新しいパッチまたは更新が利用可能になったときにワーカーを置き換えます。これは、いくつかの方法でアプローチできます。グループ内のすべてのノードが最新の AMI に置き換えられるまで、ノードを順次コーディングおよびドレインしながら、最新の AMI を使用して既存の Auto Scaling グループにインスタンスを追加できます。または、すべてのノードが置き換えられるまで、古いノードグループからノードを順次コーディングおよびドレインしながら、新しいノードグループにインスタンスを追加できます。EKS [マネージド型ノードグループは](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)最初のアプローチを使用し、新しい AMI が利用可能になると、ワーカーをアップグレードするメッセージをコンソールに表示します。 には、最新の AMI を使用してノードグループを作成し、インスタンスが終了する前にノードグループからポッドを適切に分離およびドレインするメカニズム`eksctl`もあります。ワーカーノードの置き換えに別の方法を使用する場合は、新しい更新/パッチがリリースされ、コントロールプレーンがアップグレードされたときにワーカーを定期的に置き換える必要がある可能性が高いため、人間による監視を最小限に抑えるプロセスを自動化することを強くお勧めします。 EKS Fargate では、AWS は更新が利用可能になると基盤となるインフラストラクチャを自動的に更新します。多くの場合、これはシームレスに行うことができますが、更新によってポッドが再スケジュールされることがあります。したがって、Fargate ポッドとしてアプリケーションを実行するときは、複数のレプリカを使用してデプロイを作成することをお勧めします。 ### kube-bench を定期的に実行して [Kubernetes の CIS ベンチマーク](https://www.cisecurity.org/benchmark/kubernetes/)への準拠を検証する kube-bench は、Kubernetes の CIS ベンチマークに照らしてクラスターを評価する Aqua のオープンソースプロジェクトです。このベンチマークでは、アンマネージド Kubernetes クラスターを保護するためのベストプラクティスについて説明します。CIS Kubernetes ベンチマークには、コントロールプレーンとデータプレーンが含まれます。Amazon EKS はフルマネージド型のコントロールプレーンを提供するため、CIS Kubernetes Benchmark のすべての推奨事項が適用されるわけではありません。このスコープが Amazon EKS の実装方法を反映するように、AWS は *CIS Amazon EKS Benchmark* を作成しました。EKS ベンチマークは CIS Kubernetes Benchmark から継承され、EKS クラスターに関する特定の設定上の考慮事項を含むコミュニティからの追加の入力があります。 EKS クラスターに対して [kube-bench](https://github.com/aquasecurity/kube-bench) を実行する場合は、Aqua Security の[手順に従ってください](https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md#running-cis-benchmark-in-an-eks-cluster)。詳細については、[「CIS Amazon EKS Benchmark の紹介](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark/)」を参照してください。 ### ワーカーノードへのアクセスを最小限に抑える SSH アクセスを有効にする代わりに、ホストにリモート接続する必要がある場合は [SSM Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用します。Session Manager では、紛失、コピー、共有される可能性のある SSH キーとは異なり、IAM を使用して EC2 インスタンスへのアクセスを制御できます。さらに、インスタンスで実行されたコマンドの監査証跡とログを提供します。 2020 年 8 月 19 日現在、マネージドノードグループはカスタム AMIs と EC2 起動テンプレートをサポートしています。これにより、SSM エージェントを AMI に埋め込むか、ワーカーノードがブートストラップされるときにインストールできます。Optimized AMI または ASG の起動テンプレートを変更しない場合は、[この例](https://github.com/aws-samples/ssm-agent-daemonset-installer)のように DaemonSet を使用して SSM エージェントをインストールできます。 #### SSM ベースの SSH アクセスの最小 IAM ポリシー `AmazonSSMManagedInstanceCore` AWS 管理ポリシーには、SSH アクセスを回避するだけの場合は、SSM Session Manager / SSM RunCommand に不要なアクセス許可が多数含まれています。特に懸念されるのは、 `ssm:GetParameter(s)`が パラメータストア内のすべてのパラメータ (AWS マネージド KMS キーが設定された SecureStrings を含む) にロールがアクセスできるようにするアクセス`*`許可です。 次の IAM ポリシーには、SSM Systems Manager を介したノードアクセスを有効にするための最小限のアクセス許可のセットが含まれています。 ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EnableAccessViaSSMSessionManager", "Effect": "Allow", "Action": [ "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:CreateControlChannel", "ssm:UpdateInstanceInformation" ], "Resource": "*" }, { "Sid": "EnableSSMRunCommand", "Effect": "Allow", "Action": [ "ssm:UpdateInstanceInformation", "ec2messages:SendReply", "ec2messages:GetMessages", "ec2messages:GetEndpoint", "ec2messages:FailMessage", "ec2messages:DeleteMessage", "ec2messages:AcknowledgeMessage" ], "Resource": "*" } ] } ``` このポリシーを設定し、[Session Manager プラグイン](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)をインストールすると、 を実行できます。 ``` aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE] ``` ノードにアクセスします。 **注記** また、[Session Manager のログ記録を有効にする](https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-create-iam-instance-profile.html#create-iam-instance-profile-ssn-logging)ためのアクセス許可を追加することを検討することもできます。 ### プライベートサブネットにワーカーをデプロイする ワーカーをプライベートサブネットにデプロイすることで、攻撃が頻繁に発生するインターネットへのワーカーの露出を最小限に抑えます。2020 年 4 月 22 日以降、マネージド型ノードグループのノードへのパブリック IP アドレスの割り当ては、デプロイ先のサブネットによって制御されます。これ以前は、マネージドノードグループのノードにはパブリック IP が自動的に割り当てられていました。ワーカーノードをパブリックサブネットにデプロイする場合は、AWS セキュリティグループルールを制限して公開を制限します。 ### Amazon Inspector を実行して、ホストの露出、脆弱性、ベストプラクティスからの逸脱を評価します。 [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) を使用して、ノードへの意図しないネットワークアクセスや、基盤となる Amazon EC2 インスタンスの脆弱性を確認できます。 Amazon Inspector は、Amazon EC2 Systems Manager (SSM) エージェントがインストールされ、有効になっている場合にのみ、Amazon EC2 インスタンスに一般的な脆弱性と露出 (CVE) データを提供できます。このエージェントは、EKS 最適化 [Amazon Linux AMIs を含む複数の Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。 [ AMIs](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) SSM エージェントのステータスに関係なく、すべての Amazon EC2 インスタンスがスキャンされ、ネットワーク到達可能性の問題が検出されます。Amazon EC2 のスキャンの設定の詳細については、[Amazon EC2 インスタンスのスキャン](https://docs.aws.amazon.com/inspector/latest/user/enable-disable-scanning-ec2.html)」を参照してください。 **重要** Inspector は、Fargate ポッドの実行に使用されるインフラストラクチャでは実行できません。 ## 代替方法 ### SELinux を実行する **注記** Red Hat Enterprise Linux (RHEL)、CentOS、Bottlerocket、Amazon Linux 2023 で利用可能 SELinux は、コンテナを相互およびホストから分離するための追加のセキュリティレイヤーを提供します。SELinux を使用すると、管理者はすべてのユーザー、アプリケーション、プロセス、ファイルに必須のアクセスコントロール (MAC) を適用できます。これは、一連のラベルに基づいて特定のリソースに対して実行できるオペレーションを制限するバックストップと考えてください。EKS では、SELinux を使用してコンテナが互いのリソースにアクセスできないようにできます。 Container SELinux ポリシーは [container-selinux](https://github.com/containers/container-selinux) パッケージで定義されます。Docker CE では、Docker (または他のコンテナランタイム) によって作成されたプロセスとファイルが制限されたシステムアクセスで実行されるように、このパッケージ (およびその依存関係) が必要です。コンテナは、 のエイリアスである `container_t`ラベルを使用します`svirt_lxc_net_t`。これらのポリシーにより、コンテナがホストの特定の機能にアクセスできなくなります。 Docker 用に SELinux を設定すると、Docker は自動的にワークロードをタイプ`container_t`としてラベル付けし、各コンテナに一意の MCS レベルを付与します。これにより、コンテナが互いに分離されます。より緩い制限が必要な場合は、SElinux で独自のプロファイルを作成し、ファイルシステムの特定の領域にコンテナアクセス許可を付与できます。これは、コンテナ/ポッドごとに異なるプロファイルを作成できるという点で PSPs に似ています。たとえば、一連の制限付きコントロールを持つ一般的なワークロードのプロファイルと、特権アクセスを必要とするモノのプロファイルを作成できます。 SELinux for Containers には、デフォルトの制限を変更するように設定できる一連のオプションがあります。必要に応じて、次の SELinux ブール値を有効または無効にできます。 | ブール値 | デフォルト | 説明 | | --- | --- | --- | | `container_connect_any` | `off` | コンテナがホスト上の特権ポートにアクセスできるようにします。たとえば、ホストでポートを 443 または 80 にマッピングする必要があるコンテナがある場合です。 | | `container_manage_cgroup` | `off` | コンテナが cgroup 設定を管理できるようにします。たとえば、systemd を実行しているコンテナでは、これを有効にする必要があります。 | | `container_use_cephfs` | `off` | コンテナに ceph ファイルシステムの使用を許可します。 | デフォルトでは、コンテナは で読み取り/実行`/usr`し、 からほとんどのコンテンツを読み取ることができます`/etc`。`/var/lib/docker` と の下のファイル`/var/lib/containers`には というラベルが付いています`container_var_lib_t`。デフォルトの完全なリストを表示するには、ラベルの [container.fc](https://github.com/containers/container-selinux/blob/master/container.fc) ファイルを参照してください。 ``` docker container run -it \ -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \ centos:7 cat /host/repositories.json # cat: /host/repositories.json: Permission denied docker container run -it \ -v /etc/passwd:/host/etc/passwd \ centos:7 cat /host/etc/passwd # cat: /host/etc/passwd: Permission denied ``` でラベル付けされたファイルは`container_file_t`、コンテナによって書き込み可能な唯一のファイルです。ボリュームマウントを書き込み可能にする場合は、最後に `:z`または `:Z` を指定する必要があります。 + `:z` は、コンテナが読み書きできるようにファイルのラベルを再付けします。 + `:Z` は、コンテナ**のみが**読み書きできるようにファイルを再ラベル付けします。 ``` ls -Z /var/lib/misc # -rw-r--r--. root root system_u:object_r:var_lib_t:s0 postfix.aliasesdb-stamp docker container run -it \ -v /var/lib/misc:/host/var/lib/misc:z \ centos:7 echo "Relabeled!" ls -Z /var/lib/misc #-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp ``` ``` docker container run -it \ -v /var/log:/host/var/log:Z \ fluentbit:latest ``` Kubernetes では、ラベル変更が若干異なります。Docker でファイルに自動的にラベルを変更するのではなく、カスタム MCS ラベルを指定してポッドを実行できます。再ラベル付けをサポートするボリュームは、アクセスできるように自動的に再ラベル付けされます。一致する MCS ラベルを持つポッドは、ボリュームにアクセスできます。厳密な分離が必要な場合は、ポッドごとに異なる MCS ラベルを設定します。 ``` securityContext: seLinuxOptions: # Provide a unique MCS label per container # You can specify user, role, and type also # enforcement based on type and level (svert) level: s0:c144:c154 ``` この例では、コンテナがアクセスできるファイルに割り当てられた MCS ラベル`s0:c144:c154`に対応します。 EKS では、FluentD などの特権コンテナの実行を許可するポリシーを作成し、ホストディレクトリのラベルを変更することなく、ホスト上の /var/log からの読み取りを許可する SELinux ポリシーを作成できます。同じラベルを持つポッドは、同じホストボリュームにアクセスできます。 CentOS 7 および RHEL 7 で SELinux が設定された [Amazon EKS のサンプル AMIs ](https://github.com/aws-samples/amazon-eks-custom-amis) を実装しました。これらの AMIs は、規制の厳しいお客様の要件を満たすサンプル実装を示すために開発されました。 **警告** SELinux は、タイプが閉じられていないコンテナを無視します。 ## ツールとリソース + [オンプレミスアプリケーションの SELinux Kubernetes RBAC と配送セキュリティポリシー](https://platform9.com/blog/selinux-kubernetes-rbac-and-shipping-security-policies-for-on-prem-applications/) + [Kubernetes の反復強化](https://jayunit100.blogspot.com/2019/07/iterative-hardening-of-kubernetes-and.html) + [Audit2Allow](https://linux.die.net/man/1/audit2allow) + [SEAlert](https://linux.die.net/man/8/sealert) + [Udica を使用してコンテナの SELinux ポリシーを生成する](https://www.redhat.com/en/blog/generate-selinux-policies-containers-with-udica) は、Linux の機能、ポート、マウントポイントのコンテナ仕様ファイルを調べ、コンテナを適切に実行できるようにする一連の SELinux ルールを生成するツールを記述します。 + さまざまな規制要件を満たすために OS を強化するための [AMI 強化](https://github.com/aws-samples/amazon-eks-custom-amis#hardening)プレイブック + [Keiko Upgrade Manager](https://github.com/keikoproj/upgrade-manager) は、ワーカーノードのローテーションを調整する Intuit のオープンソースプロジェクトです。 + [Sysdig Secure](https://sysdig.com/products/kubernetes-security/) + [eksctl](https://eksctl.io/)