インフラストラクチャ (ホスト) の保護

コンテナイメージを保護することは重要ですが、コンテナイメージを実行するインフラストラクチャを保護することも同様に重要です。このセクションでは、ホストに対して直接起動される攻撃によるリスクを軽減するさまざまな方法について説明します。これらのガイドラインは、「ランタイムセキュリティ」セクションで説明されているガイドラインと組み合わせて使用する必要があります。

レコメンデーション

コンテナの実行に最適化された OS を使用する

Linux コンテナの実行用に設計された AWS の専用 OS である Flatcar Linux、Project Atomic、RancherOS、Bottlerocket の使用を検討してください。これには、攻撃対象領域の削減、起動時に検証されるディスクイメージ、SELinux を使用した強制アクセス許可の境界が含まれます。

または、Kubernetes ワーカーノードの EKS 最適化 AMI を使用します。EKS 最適化 AMI は定期的にリリースされ、コンテナ化されたワークロードを実行するために必要な最小限の OS パッケージとバイナリのセットが含まれています。

Hashicorp Packer を使用して Red Hat Enterprise Linux で実行されているカスタム Amazon EKS AMI を構築するために使用できるサンプル設定スクリプトについては、Amazon EKS AMI RHEL ビルド仕様を参照してください。このスクリプトをさらに活用して、STIG 準拠の EKS カスタム AMIs を構築できます。

ワーカーノード OS を最新の状態に保つ

Bottlerocket などのコンテナ最適化ホスト OS を使用するかどうかにかかわらず、EKS 最適化 AMIs などの Amazon マシンイメージでは、これらのホスト OS イメージを最新のセキュリティパッチで最新の状態に保つことをお勧めします。

EKS 最適化 AMIs、CHANGELOG および/またはリリースノートチャネルを定期的にチェックし、更新されたワーカーノードイメージのクラスターへのロールアウトを自動化します。

インフラストラクチャをイミュータブルとして扱い、ワーカーノードの交換を自動化する

インプレースアップグレードを実行するのではなく、新しいパッチまたは更新が利用可能になったときにワーカーを置き換えます。これは、いくつかの方法でアプローチできます。グループ内のすべてのノードが最新の AMI に置き換えられるまで、ノードを順次コーディングおよびドレインしながら、最新の AMI を使用して既存の Auto Scaling グループにインスタンスを追加できます。または、すべてのノードが置き換えられるまで、古いノードグループからノードを順次コーディングおよびドレインしながら、新しいノードグループにインスタンスを追加できます。EKS マネージド型ノードグループは最初のアプローチを使用しており、新しい AMI が利用可能になると、ワーカーをアップグレードするためのメッセージがコンソールに表示されます。には、最新の AMI を使用してノードグループを作成し、インスタンスが終了する前にノードグループからポッドを適切に分離およびドレインするためのメカニズムeksctlもあります。ワーカーノードの置き換えに別の方法を使用する場合は、新しい更新/パッチがリリースされ、コントロールプレーンがアップグレードされたときにワーカーを定期的に置き換える必要がある可能性が高いため、人間による監視を最小限に抑えるプロセスを自動化することを強くお勧めします。

EKS Fargate では、AWS は更新が利用可能になると基盤となるインフラストラクチャを自動的に更新します。多くの場合、これはシームレスに行うことができますが、更新によってポッドが再スケジュールされることがあります。したがって、Fargate ポッドとしてアプリケーションを実行するときは、複数のレプリカを使用してデプロイを作成することをお勧めします。

kube-bench を定期的に実行して Kubernetes の CIS ベンチマークへの準拠を検証する

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 を実行する場合は、Aqua Security の手順に従ってください。詳細については、「CIS Amazon EKS Benchmark の紹介」を参照してください。

ワーカーノードへのアクセスを最小限に抑える

SSH アクセスを有効にする代わりに、ホストにリモート接続する必要がある場合は SSM Session Manager を使用します。Session Manager では、紛失、コピー、共有される可能性のある SSH キーとは異なり、IAM を使用して EC2 インスタンスへのアクセスを制御できます。さらに、インスタンスで実行されたコマンドの監査証跡とログを提供します。

2020 年 8 月 19 日現在、マネージド型ノードグループはカスタム AMIs と EC2 起動テンプレートをサポートしています。これにより、SSM エージェントを AMI に埋め込むか、ワーカーノードがブートストラップされるときにインストールできます。Optimized AMI または ASG の起動テンプレートを変更しない場合は、この例のように DaemonSet を使用して SSM エージェントをインストールできます。

SSM ベースの SSH アクセスの最小 IAM ポリシー

AmazonSSMManagedInstanceCore AWS 管理ポリシーには、SSH アクセスを回避するだけの場合は、SSM Session Manager / SSM RunCommand に不要なアクセス許可が多数含まれています。特に懸念されるのは、 ssm:GetParameter(s)が Parameter Store のすべてのパラメータ (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 プラグインをインストールすると、を実行できます。


aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

ノードにアクセスします。

注記

Session Manager のログ記録を有効にするためのアクセス許可の追加を検討することもできます。

プライベートサブネットにワーカーをデプロイする

ワーカーをプライベートサブネットにデプロイすることで、攻撃が頻繁に発生するインターネットへのワーカーの露出を最小限に抑えます。2020 年 4 月 22 日以降、マネージド型ノードグループのノードへのパブリック IP アドレスの割り当ては、デプロイ先のサブネットによって制御されます。これ以前は、マネージド型ノードグループのノードにはパブリック IP が自動的に割り当てられていました。ワーカーノードをパブリックサブネットにデプロイする場合は、AWS セキュリティグループルールを制限して公開を制限します。

Amazon Inspector を実行して、ホストの露出、脆弱性、ベストプラクティスからの逸脱を評価します。

Amazon Inspector を使用して、ノードへの意図しないネットワークアクセスや、基盤となる Amazon EC2 インスタンスの脆弱性を確認できます。

Amazon Inspector は、Amazon EC2 Systems Manager (SSM) エージェントがインストールされ、有効になっている場合にのみ、Amazon EC2 インスタンスに一般的な脆弱性と露出 (CVE) データを提供できます。このエージェントは、EKS 最適化 Amazon Linux AMIs を含む複数の Amazon マシンイメージ (AMI) にプリインストールされています。 AMIs SSM エージェントのステータスに関係なく、すべての Amazon EC2 インスタンスがスキャンされ、ネットワーク到達可能性の問題が検出されます。Amazon EC2 のスキャンの設定の詳細については、Amazon EC2 インスタンスのスキャン」を参照してください。

重要

Inspector は、Fargate ポッドの実行に使用されるインフラストラクチャでは実行できません。

代替方法

SELinux を実行する

注記

Red Hat Enterprise Linux (RHEL)、CentOS、Bottlerocket、Amazon Linux 2023 で利用可能

SELinux は、コンテナを相互に分離し、ホストから分離するための追加のセキュリティレイヤーを提供します。SELinux を使用すると、管理者はすべてのユーザー、アプリケーション、プロセス、ファイルに必須のアクセスコントロール (MAC) を適用できます。これは、一連のラベルに基づいて特定のリソースに対して実行できるオペレーションを制限するバックストップと考えてください。EKS では、SELinux を使用して、コンテナが互いのリソースにアクセスできないようにできます。

Container SELinux ポリシーは 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 ファイルを参照してください。


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 を実装しました。これらの AMIs は、規制の厳しいお客様の要件を満たすサンプル実装を示すために開発されました。

警告

SELinux は、タイプが閉じられていないコンテナを無視します。

ツールとリソース

オンプレミスアプリケーションの SELinux Kubernetes RBAC と配送セキュリティポリシー
Kubernetes の反復強化
Audit2Allow
SEAlert
Udica を使用してコンテナの SELinux ポリシーを生成するは、Linux の機能、ポート、マウントポイントのコンテナ仕様ファイルを調べ、コンテナを適切に実行できる一連の SELinux ルールを生成するツールを記述します。
AMI Hardening プレイブックは、さまざまな規制要件に合わせて OS を強化します。
Keiko Upgrade Manager は、ワーカーノードのローテーションを調整する Intuit のオープンソースプロジェクトです。
Sysdig Secure
eksctl

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ランタイムセキュリティ

規制コンプライアンス