コンテナサービスを対象にしたConfigのAWSマネージドルールをまとめてみた

こんにちは。枡川です。

昨年2月にAWS Configがコンテナサービス(ECS、ECR、EKS)をサポートしました。
サポートしてから1年経ち、AWSマネージドのConfigルールも増えていたのでまとめてみました。

ConfigがサポートしているAWSリソース

現在AWS Configがサポートしているコンテナ系のリソースは下記です。

Amazon Elastic Container Registry(ECR)

• AWS::ECR::Repository

Amazon Elastic Container Service (ECS)

• AWS::ECS::Cluster
• AWS::ECS::TaskDefinition
• AWS::ECS::Service
• AWS::ECS::TaskSet

Amazon Elastic Kubernetes Service(EKS)

• AWS::EKS::Cluster

コンテナ系のConfigマネージドルール

AWS Configルールは各設定にルールを設けて、適切にルールが守られているかを自動で確認するサービスです。
AWSマネージドルールとカスタムルールの2種類が存在します。
AWSマネージドルールの場合、Lambdaを作成および管理する必要が無くなるので非常に楽できます。
Configルールそのものについては下記ブログが参考になります！

AWSマネージドのConfigルールの中でコンテナサービスを対象にしたものは下記があります。(2022年2月現在)

ECR

ecr-private-image-scanning-enabled

プライベートECRリポジトリでイメージスキャンが有効になっているかどうかを確認します。
トリガータイプ: 設定変更時

ecr-private-tag-immutability-enabled

プライベートECRリポジトリでタグのイミュータビリティが有効になっているかどうかを確認します。
トリガータイプ: 設定変更時

ECS

ecs-containers-nonprivileged

タスク定義の特権付与パラメータが「true」に設定されているかどうかを確認します。
※このパラメータがtrueの時、コンテナにはホストコンテナインスタンスに対する昇格されたアクセス権限(root ユーザーと同様)が付与されます。Fargate起動タイプの場合はそもそもパラメータを選択することができないため必ず準拠になります。
トリガータイプ: 設定変更時

ecs-containers-readonly-access

コンテナがルートファイルシステムへの読み取り専用アクセスのみを持っているかどうかを確認します。
トリガータイプ: 設定変更時

ecs-no-environment-secrets

タスク定義でシークレットを環境変数として渡しているかどうかを確認します。
「secretKeys」パラメーターにキーを渡して、それらがタスク定義の環境変数に設定されているかどうかを確認します。
トリガータイプ: 設定変更時
パラメータ:secretKeys(カンマ区切りのキーのリスト)

ecs-task-definition-memory-hard-limit

タスク定義にメモリ制限が設定されているかどうかを確認します。
トリガータイプ: 設定変更時

ecs-task-definition-nonroot-user

EC2起動タイプを選択した際に、タスク定義で実行するユーザーを指定しているかどうかを確認します。
「user」パラメータが存在しないか、rootに設定されている場合に非準拠とみなします。
トリガータイプ: 設定変更時

ecs-task-definition-pid-mode-check

タスク定義がホストのプロセス名前空間をECSコンテナと共有するように設定されているかどうかを確認します(pidModeパラメータ)。
※Fargate起動タイプの場合はそもそもパラメータを選択することができないため、必ず準拠になります。
トリガータイプ: 設定変更時

ecs-task-definition-user-for-host-mode-check

ホストネットワークモードな上に、特権付与パラメータが「true」か「user」がrootになっていないかを確認します。
トリガータイプ: 設定変更時
パラメータ:SkipInactiveTaskDefinitions(オプションのパラメータ、ACTIVEなタスク定義のみを対象にする場合はTrue)

ECRとECSについてecs-containers-readonly-accessのみ大阪リージョンも含めて対応しているという状況でした。(東京リージョンはすべて対応)
今後いろいろと追加されることに期待です。

EKS

eks-cluster-oldest-supported-version

クラスターがサポートされている最も古いバージョンを実行している場合に非準拠とします。
トリガータイプ: 設定変更時

eks-cluster-supported-version

クラスターがサポートされているバージョンを実行していない場合に非準拠とします。
トリガータイプ: 設定変更時

eks-endpoint-no-public-access

EKSエンドポイントがパブリックにアクセス可能であるかを確認します。
トリガータイプ: 定期的

eks-secrets-encrypted

EKSクラスターが、KMSキーを使用してKubernetesシークレットを暗号化しているかを確認します。
トリガータイプ: 定期的
パラメータ: kmsKeyArns (オプションのパラメータ、EKSを暗号化するために使用するKMSキーのARN)

AWSマネージドルールがかなり増えていました。
これらのルールはセキュリティ上特に大事なものと考えられるので、何が違反するか確かめてみるのも面白いですね！
各ルールに対して、非準拠のものは一覧で確認することができます。
コンテナサービスに限らず、マネージドルール一覧は下記リンク先に記載されています。
(一部、英語版で見ないと表示されないルールがあります。特にコンテナ系はほとんど表示されません。)

料金について

AWS Configでは、記録された設定項目（configuration item recorded）ごとに 0.003 USDかかります。（2022年2月時点の東京リージョンの場合。）
さらに、Configルールの評価数に応じて下記料金が発生します。

(参考)AWS Configの料金

特にAWS::ECS::TaskDefinitionについては、タスク定義を更新する度に新しいリビジョンが別リソースとして作成され、管理されます。
また、AWS::ECS::Serviceについても参照するタスク定義が変わると設定変更扱いとなります。
Configルールを設定していれば、その度に評価した分だけ料金が発生します。
CI/CDパイプラインを構築して一日に何度もタスク定義の新しいバージョンを作成するような場合では、それなりの額が発生します。
とはいえ、便利なAWSマネージドルールも存在するので上手く活用するに越したことがないのも事実です。
当たり前ではありますが、管理したい設定項目がある場合に使用して、なんとなくでは有効にしないことをおすすめします。

また、ECRについてはイメージのpush時に毎回設定変更扱いにはなりませんでした。
イメージスキャンは有効化しておいて損は無い機能だと思いますし、latest運用をやめようという意思がある場合はとてもおすすめです。
latest運用をなぜ避けるべきかは下記ブログで詳しく語られているので、紹介しておきます！

まとめ

セキュリティのガイドラインを決めたとしても、きちんと満たしているかをチェックするのは面倒ですし、ミスも起きがちです。
AWSマネージドのサービスを使って少しでも楽をしつつチェックしていきたいですね！