コンテナのセキュリティ対策まとめ

はじめに

クラウドネイティブ学習の一環として、コンテナにおけるセキュリティ対策について学びました。
今回学んだこと忘れず実務で必要になった時に参照できるよう、記事にまとめました。

コンテナのセキュリティ対策

コンテナ型アプリケーションにおいて、コンテナに対するセキュリティ対策は、従来型のサーバ型仮想化（ハイパーバイザー型）とは異なるアプローチが必要となる。
コンテナを構成する階層ごとに脆弱性が存在し、それぞれセキュリティ対策が必要。
具体的には、下記のレイヤーに分けられる。

• コンテナイメージ
• レジストリ
• オーケストレータ（Kubernetes）
• コンテナ
• ホスト
• コード

コンテナイメージ

• コンテナイメージには、ベースイメージとアプリケーションフレームワークといった各種ソフトウェアから構成されており、インストールされたツールに既知の脆弱性が内在する恐れがある。
• ツールの脆弱性に十分対処していたとしても、人的な不備により、Dockerfileテンプレートにセキュリティ上危険な設定が記述されている可能性がある。
• イメージへの脆弱性対策として、イメージに対する脆弱性スキャンを継続的に実行することが必要。
  • イメージスキャナによって、主に下記項目を検出する。
    ・イメージの脆弱性
    ・信頼できないイメージの使用
    ・独自のチェック項目（業界的なコンプライアンスに準拠しているかどうか等）
    ・マルウェア
    ・シークレット情報（平文パスワード、SSH秘密鍵等）
  • イメージスキャナツールとしてはTrivy, Dockleがある。またAWSでは、Inspcetor v2によりECRに格納されたイメージの継続的スキャンが可能。これらツールは要件に応じて組み合わせて利用する。
• イメージのスリム化もイメージの脆弱性対策に有効。
  • イメージ軽量化はアプリケーションのパフォーマンス向上に寄与するだけでなく、攻撃対象の削減にもなる。
  • スクラッチイメージから必要なランタイム、ツールのみインストールする 「加算アプローチ」 を検討する。
  • 必要なければシェルプログラム（/bin/sh, /bin/bash）はイメージに含めない。
    → 攻撃者がコンテナ内のシェルを奪取してリモートコマンド実行することを防止

レジストリ

• クラウドのレジストリサービスとしては、AWS ECRやAzure ContainerRegistryがあるが、必要最低限のユーザ/サービスからのみアクセス許可し、通信経路もセキュアなもののみに限定するといった対策が必要。
• AWSでいえば、下記のような対策があげられる。
  • ECRにアクセス可能なIAMロール/IAMユーザの管理
  • ECR側で権限管理したい場合は、リポジトリポリシーの使用も検討
  • ECR用VPCエンドポイントの使用（セキュアな通信経路の確保）
• 古い使っていないイメージが溜まりリポジトリが肥大化していく恐れがあるため、定期的なチェックと不要イメージのクリーンナップが必要。
  →誤ったイメージの使用防止

オーケストレータ（Kubernetes）

オーケストレータのセキュリティ対策は非常に多岐にわたるため、ここでは一部のみ簡単に記載する。（余力があれば別で記事作りたい）

• コントロールプレーンの保護
  • プライベートAPIエンドポイントのみの使用（VPC内からのアクセスのみ許可）
  • パブリックAPIエンドポイントを使用する場合は、IPによるアクセス制限
• dev/stg/prdといった環境別でのnamespaceの分離
• RBACによる、職務別（ex:開発者、テスター、クラスター管理者等）でのK8sリソースへのアクセス制御

コンテナ

K8s等オーケストレータによりデプロイされたコンテナに脆弱性があり侵害された場合、その影響範囲は単独のコンテナ内にとどまらない。
そのため被害を最小限に抑えることを目的に、下記のような対策が必要。（K8マニフェストで設定可能）

• Podに付与されるホスト（ノード）へのアクセス権限最小化
• Podのホストへのファイルマウント最小化
• 必要ない限り、コンテナ間通信を無効化
• Linuxセキュリティモジュール（seccomp, AppArmor, SELinux）を使用

ホスト（K8sノード）

コンテナを稼働させるホストへのセキュリティ侵害防止には、下記が考えられる。

• データプレーンにマネージドサービスを利用しセキュリティ運用を省略
  • ex:EKSなら、EC2ではなくAWS Fargateを使う。
  • 起動速度や料金等の問題があるため、要件によりFargateを使えるか検討が必要。
• コンテナに 最適化されたOS（CoreOS, RancherOS） を使用して攻撃対象領域を削減
• ホストへのリモートアクセスを最小化
  • SSHは廃止し、セッションマネージャによるアクセスに限定など

コード

　IaC（CloudFormation, Terraform, K8sマニフェスト等）によってインフラを構成管理することで、構築の属人化防止やベースラインの確保が可能になった。
　それに加えIaC導入により、セキュリティ的な観点でもテンプレートの静的セキュリティスキャンが可能になり自動的・継続的なセキュリティ問題の検知の仕組みも構築しやすくなった。
　以下のような対策を検討する必要がある。

• デプロイ前の静的スキャン

  • インフラコードもアプリケーションコードと同様、CI/CDパイプラインによりデプロイ前に静的スキャンを行い自動テストすることで、インフラ構成の継続的な脆弱性対策が可能。
  • コードのセキュリティスキャンツールとしてtrivyなどが利用可能。以下のような脆弱性を検知する。
    ・過剰な権限を有するロール
    ・サービスの外部公開
    ・暗号化されていないストレージ
    ・不十分なロギング

• ドリフトの監視

  • デプロイ後であっても、ユーザが手動で構成に変更を加え想定外の脆弱性が発生する恐れがある。そこで構成ドリフトを継続的に検出することが望ましい。
  • AWSでは、ConfigとEventBridgeの組み合わせにより継続的なドリフト監視・自動通知が可能。
    （参考：AWS CloudFormationスタックのドリフトを検出してSlackに通知する）

• 宣言的セキュリティポリシー制御

  • OPA(Open Policy Agent) によりKubernetes APIへのkubectlリクエストに対し、認可制御を実装できる。
  • OPAポリシー（ユーザのどのようなkubectl操作を許可するか）はRegoという言語で記述できる。
    （このような、ポリシーを宣言的に定義することをPolicy as Codeと呼ぶ。）

参考記事

• クラウドネイティブセキュリティ入門
• NECセキュリティブログ - コンテナイメージのセキュリティ
• Open Policy Agent とは？