コンテナセキュリティのベストプラクティス

本文の内容は、2021年10月12日に Álvaro Iradierが投稿したブログ(https://sysdig.com/blog/container-security-best-practices/）を元に日本語に翻訳・再構成した内容となっております。 コンテナセキュリティのベストプラクティスにこだわることは、検証済みソフトウェアの提供を成功させるだけでなく、深刻なセキュリティ侵害とその結果を防ぐためにも重要です。 2020年のCNFC調査によると、92％の企業が本番環境でコンテナを使用しており、2016年から300％増加しています。このように、KubernetesやOpenshiftなどのコンテナ技術はあらゆる場所に存在しています。 しかし、コンテナは安全で隔離されたものではないのでしょうか？まあ、そんなところです。 例えば、コンテナ内部の悪用可能な脆弱性が、露出したメタデータや誤った認証情報の設定と組み合わさると、クラウドのインフラ全体を危険にさらすことになります。クラウドラテラルムーブメントの記事で説明したように、ハッカーは、この一連の脆弱性と誤った設定を利用して、お客様のクラウドアカウントでクリプトマイニングアプリケーションを実行することができます。 コンテナは、自己完結型アプリケーションの配布メカニズムとして設計されており、分離された環境でプロセスを実行できるようになっています。 分離の目的で、カーネルカーネルネームスペースを使用する軽量メカニズムを採用し、完全なオペレーティングシステム、CPUとハードウェアの仮想化など、VM内のいくつかの追加レイヤーの要件を排除しています。 このような追加の抽象化レイヤーがないことや、カーネル、オペレーティングシステム、コンテナランタイムとの緊密な結合により、コンテナの内部から外部へ、またはその逆にジャンプするためのエクスプロイトが利用しやすくなります。 コンテナセキュリティの機能イメージ コンテナセキュリティのベストプラクティスには、配信されるアプリケーションやコンテナイメージ自体だけでなく、コンテナのビルド、配布、特別な実行に使用されるコンポーネントスタック全体も含まれます。 これには以下が含まれます：

• ホストまたはVM
• コンテナのランタイム
• クラスター技術
• クラウドプロバイダーの構成
• などがあります。

複雑なスタック

• コンテナは、従来のVMイメージよりもはるかに軽量でありながら、すべてのライブラリと依存関係を含む自己完結型の実行イメージとして、ソフトウェアを配布・実行するための非常に便利な方法です。
• カーネルネームスペースを使用して、マウント、PID、ネットワーク、IPCなどを含む独自の “jail “内でプロセスを実行することで、優れたレベルのセキュリティと分離を提供し、カーネルcgroupsを介してCPU使用量とメモリをリソース制限します。メモリ保護やパーミッションの適用などは、標準的なカーネルセキュリティメカニズムを介して行われます。

• プロバイダーは、ベースとなるピースの動作とセキュリティの維持に責任を持ちます。
• そして、あなたは上位レイヤーに集中することができます。

予防：シフトレフトセキュリティにおける8つのステップ

1. CI/CDプロセスにコードスキャンを組み込む

• コード
• 依存関係
• コードとしてのインフラ
• コンテナイメージ
• ホスト
• クラウド構成
• …などなど

name: "Security Scan"
on:
  push:
jobs:
  tests:
    runs-on: ubuntu-latest
    env:
      GO111MODULE: on
    steps:
      - name: Checkout Source
        uses: actions/checkout@v2
      - name: Run Gosec Security Scanner
        uses: securego/gosec@master
        with:
          args: ./...

2. 依存性スキャンによる外部脆弱性の低減

<project>
    ...
    <build>
        ...
        <plugins>
            ...
            <plugin>
              <groupId>org.owasp</groupId>
              <artifactId>dependency-check-maven</artifactId>
              <version>6.2.2</version>
              <executions>
                  <execution>
                      <goals>
                          <goal>check</goal>
                      </goals>
                  </execution>
              </executions>
            </plugin>
            ...
        </plugins>
        ...
    </build>
    ...
</project>

3. コンテナイメージの分析にイメージスキャンを使用する

name: "Security Scan"
on:
  push:
jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Build the Docker image
      run: docker build . --file Dockerfile --tag my-image:latest
    - name: Scan image
      id: scan
      uses: sysdiglabs/scan-action@v3
      with:
        image-tag: my-image:latest
        sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }}
        input-type: docker-daemon
        run-as-user: root

4. イメージコンテンツの信頼性確保

$ docker trust key generate example1
Generating key for example1...
Enter passphrase for new example1 key with ID 7d7b320:
Repeat passphrase for new example1 key with ID 7d7b320:
Successfully generated and loaded private key. Corresponding public key available: /Users/airadier/example1.pub

$HOME/example1.pub

$HOME/.docker/trust/private/<key ID>.key

$ docker trust signer add --key example1.pub example1 airadier/alpine
Adding signer "example1" to airadier/alpine...
Initializing signed repository for airadier/alpine...
...
Enter passphrase for new repository key with ID 16db658:
Repeat passphrase for new repository key with ID 16db658:
Successfully initialized "airadier/alpine"
Successfully added signer: example1 to airadier/alpine

$ docker trust sign airadier/alpine:latest
Signing and pushing trust data for local image airadier/alpine:latest, may overwrite remote trust data
The push refers to repository [docker.io/airadier/alpine]
bc276c40b172: Layer already exists
latest: digest: sha256:be9bdc0ef8e96dbc428dc189b31e2e3b05523d96d12ed627c37aa2936653258c size: 528
Signing and pushing trust metadata
Enter passphrase for example1 key with ID 7d7b320:
Successfully signed docker.io/airadier/alpine:latest

$ export DOCKER_CONTENT_TRUST=1
$ docker push airadier/alpine:3.11
The push refers to repository [docker.io/airadier/alpine]
3e207b409db3: Layer already exists
3.11: digest: sha256:39eda93d15866957feaee28f8fc5adb545276a64147445c64992ef69804dbf01 size: 528
Signing and pushing trust metadata
Enter passphrase for example1 key with ID 7d7b320:
Successfully signed docker.io/airadier/alpine:3.11

$ docker trust inspect --pretty airadier/alpine:latest
Signatures for airadier/alpine:latest
SIGNED TAG   DIGEST                                                             SIGNERS
latest       be9bdc0ef8e96dbc428dc189b31e2e3b05523d9...   example1
List of signers and their keys for airadier/alpine:latest
SIGNER     KEYS
example1   7d7b320791b7
Administrative keys for airadier/alpine:latest
  Repository Key:       16db658159255bf0196...
  Root Key:             2308d2a487a1f2d499f184ba...

$ export DOCKER_CONTENT_TRUST=1
$ docker pull airadier/alpine-ro:latest
Error: remote trust data does not exist for docker.io/airadier/alpine-ro: notary.docker.io does not have trust data for docker.io/airadier/alpine-ro

5. よくあるセキュリティの設定ミスと改善策

ホストベンチマークコントロール例

Linuxディストリビューションの例

コンテナランタイムのベンチマークコントロールの例

オーケストレーターベンチマークコントロールの例

クラウドベンチマークコントロールの例

6. IaCスキャンの導入

$ pip install checkov
$ checkov --quiet -d .
       _               _
   ___| |__   ___  ___| | _______   __
  / __| '_ \ / _ \/ __| |/ / _ \ \ / /
 | (__| | | |  __/ (__|   < (_) \ V /
  \___|_| |_|\___|\___|_|\_\___/ \_/
By bridgecrew.io | version: 2.0.346
terraform scan results:
Passed checks: 314, Failed checks: 57, Skipped checks: 0
Check: CKV_AWS_108: "Ensure IAM policies does not allow data exfiltration"
        FAILED for resource: aws_iam_policy_document.cloudtrail_ingestor
        File: /modules/ingestor/main.tf:17-31
        Guide: https://docs.bridgecrew.io/docs/ensure-iam-policies-do-not-allow-data-exfiltration
                17 | data "aws_iam_policy_document" "ingestor" {
                18 |   statement {
                19 |     effect = "Allow"
                20 |     actions = [
                21 |       "s3:Get*",
                22 |       "s3:List*",
                23 |       "s3:Put*",
                24 |       "s3:Head*",
                25 |       "sqs:DeleteMessage",
                26 |       "sqs:DeleteMessageBatch",
                27 |       "sqs:ReceiveMessage",
                28 |     ]
                29 |     resources = ["*"]
                30 |   }
                31 | }
...

7. ホストスキャンによるホストの保護

8. 安全でないコンテナの実行を防ぐ

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredannotations
  annotations:
    description: Requires all resources to contain a specified annotation(s) with a value
      matching a provided regular expression.
spec:
 ...
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredannotations
        violation[{"msg": msg, "details": {"missing_annotations": missing}}] {
            provided := {annotation | input.review.object.metadata.annotations[annotation]}
            required := {annotation | annotation := input.parameters.annotations[_].key}
            missing := required - provided
            count(missing) > 0
            msg := sprintf("you must provide annotation(s): %v", [missing])
        }
        violation[{"msg": msg}] {
          value := input.review.object.metadata.annotations[key]
          expected := input.parameters.annotations[_]
          expected.key == key
          expected.allowedRegex != ""
          not re_match(expected.allowedRegex, value)
          msg := sprintf("Annotation <%v: %v> does not satisfy allowed regex: %v", [key, value, expected.allowedRegex])
        }

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredAnnotations
metadata:
  name: all-must-have-certain-set-of-annotations
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Service"]
  parameters:
    message: "All services must have a `a8r.io/owner` and `a8r.io/runbook` annotations."
    annotations:
      - key: a8r.io/owner
        # Matches email address or github user
        allowedRegex: ^([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}|[a-z]{1,39})$
      - key: a8r.io/runbook
        # Matches urls including or not http/https
        allowedRegex: ^(http:\/\/www\.|https:\/\/www\.|http:\/\/|https:\/\/)?[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(:[0-9]{1,5})?(\/.*)?$

プロテクション – コンテナを安全に稼働させる

9. リソースの保護

• VM、VPC、インターネット間の通信を制限するために、クラウド事業者ではVPC、セキュリティグループ、ネットワークルール、ファイアウォールルールなどがあります。
• ホストレベルのファイアウォールでは、必要最小限のサービスのみを公開します。
• クラスターにはKubernetesのネットワークポリシーを適用し、Service MeshやAPI Gatewayなどのツールを追加することで、ネットワークリクエストをフィルタリングするための追加のセキュリティレイヤーを追加することができます。

10. イメージ署名の検証

11. ランタイム時にコンテナの権限を制限する

• 有効なユーザー：コンテナを root として実行しない。さらに良いのは、ホスト内の実際のユーザーにマッピングされないランダムなUID（Openshiftのような）を使用するか、DockerやKubernetesのユーザーネームスペース機能を準備ができ次第使用することです（本記事公開時には利用できていません）。
• コンテナの権限を制限する：DockerとKubernetesは、能力を落とす方法を提供し、特権的なコンテナを許可しません。SeccompとAppArmorは、コンテナが実行できるアクションの範囲にさらに制限を加えることができます。
• リソース制限を追加する：コンテナがすべてのメモリやCPUを消費して、他のアプリケーションが飢えてしまうことを避ける。
• 共有ストレージやボリュームに注意する：具体的には、hostPath のようなもので、ホストからのファイルシステムを共有します。
• hostNetwork、hostPID、hostIPCなどの他のオプション：Kubernetesはコンテナがホストとネームスペースを共有し、隔離性を低下させます。
• Pod Security Policies（PSP）とSecurity Context Constraints（OpenshiftではSCC）を定義する：クラスターにガードレールを設定し、コンテナの設定ミスを防ぎます。PSPとSCCはアドミッションコントローラーで、セキュリティコンテキストが定義されたポリシーに準拠していない場合にポッドを拒否します。

12. コンテナの脆弱性を賢く管理する

• 修正すべきものの優先順位をつける：ホストやコンテナの脆弱性のうち、スコアや深刻度が高いものに焦点を当てるべきです。これは、リモートから悪用可能であり、公開されたエクスプロイトが利用可能であることを意味することが多いです。脆弱性が古くてよく知られている場合は、自動化された方法で積極的に悪用されている可能性が高くなります。
• あなたの環境における脆弱性の深刻度を評価してください：ベンダーや使用しているLinuxディストリビューションが提供するスコアや深刻度は良い出発点です。しかし、脆弱性がリモートから悪用可能で、インターネットにさらされていない内部ホストの未使用のパッケージに存在する場合、その脆弱性は高いスコアを得ることができます。そして、それは本番環境でも、開発者の遊び場や実験用のクラスターでも構いません。状況に応じて影響を評価し、それに応じた計画を立てましょう。
• コンテナやホストを保護するための対策として、修正プログラムの適用を計画します：チケットを作成して追跡し、脆弱性管理を標準的な開発ワークフローの一部にしましょう。
• 影響がないと判断した場合は、脆弱性の例外を作成する：これにより、ノイズを減らすことができます。例外を恒久的に追加するのではなく、スヌーズを検討し、後で再評価できるようにします。

• チケッティング：検出された脆弱性を開発者に通知し、開発者が修正プログラムを適用できるようにする。
• イメージレジストリ：脆弱性のあるイメージが全て引き出されないようにする。
• ホスト / カーネル / コンテナ：ランタイム中のコンテナをブロックしたり、保護手段を追加したり、重大な問題が発生したホストやコンテナをKill、隔離、シャットダウンして対応する。

検出 – 異常な振る舞いに対するアラート

13. リアルタイムのイベントおよびログ監査のセットアップ

• ホストおよびKubernetesのログ
• クラウドログ（AWSのCloudTrail、GCPのActivity Auditなど）
• コンテナ内のシステムコール

• MITRE ATT&CKにおける検出：Falco における特権エスカレーション
• MITRE ATT&CKにおける検出：Falcoを用いた防衛回避(Defense Evasion)テクニック

rule: ECS Task Run or Started
condition: aws.eventSource="ecs.amazonaws.com" and (aws.eventName="RunTask" or aws.eventName="StartTask") and not aws.errorCode exists
output: A new task has been started in ECS (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region, cluster=%jevt.value[/requestParameters/cluster], task definition=%aws.ecs.taskDefinition)
source: aws_cloudtrail
description: Detect a new task is started in ECS.

14. リソースの監視

インシデント対応とフォレンジック

• そのセキュリティインシデントが実際の攻撃なのか、それとも単なるコンポーネントの誤動作なのか。
• 具体的に何が起こったのか、どこで発生したのか、影響を受ける可能性のあるコンポーネントは他にあるのか。
• どのようにしてセキュリティインシデントの再発を防ぐことができるか。

15. 隔離と調査

• 停止とスナップショット： 可能な限り、ホストやコンテナを隔離します。コンテナのランタイムが提供するのは、コンテナを「一時停止」するか（「docker pause」コマンドなど）、スナップショットを取ってから停止することでした。ホストの場合は、ファイルシステムレベルでスナップショットを取ってから停止させることが考えられます。EC2やVMインスタンスの場合は、インスタンスのスナップショットを取ることもできます。その後、隔離に進みます。スナップショットを、ネットワークのない安全なサンドボックス環境にコピーして、ホストやコンテナを再開することができます。
• 探索とフォレンジック： 隔離が完了したら、理想的にはライブのコンテナやホストを探索して、実行中のプロセスを調査します。ホストやコンテナが生きていない場合は、ファイルシステムのスナップショットに注目してください。ログや変更されたファイルを調査します。Sysdig Secure captures のように、イベント発生時のシステムコールをすべて記録することでフォレンジック機能を大幅に強化するツールがありますので、コンテナやホストが死んだ後でも調査することができます。
• 最後の手段として、侵害されたコンテナやホストを破壊します：疑わしいアクティビティを破壊するだけで、短期的にはさらなる被害を防ぐことができます。しかし、何が起こったのか詳細がわからないと、再発を防ぐことができません。また、次の攻撃が起こるのを待って、再びKillすることを繰り返すという、終わりのないモグラ叩きのような状況に陥る可能性があります。

16. 設定ミスの修正

17. 脆弱性へのパッチ

• オペレーティングシステムのパッケージ（dpkg、rpmなど）の場合：まず、配布ベンダーが修正プログラムを含むパッケージの更新版を提供しているかどうかを確認してください。パッケージまたはコンテナのベースイメージを更新してください。
• 古いディストリビューションのバージョン：ベンダーが更新版やセキュリティフィックスの提供を停止します。手遅れになる前に、ホストやイメージをサポートされたバージョンにしておきましょう。
• NodeJS、Go、Javaなどの言語パッケージの場合：依存関係の更新バージョンをチェックします。大きなバージョンの更新で起こりうる破壊的な変更の計画やテストに時間をかけられない場合は、セキュリティ問題を修正するだけのマイナーアップデートやパッチバージョンを探しましょう。しかし、古いバージョンが永遠に維持されるわけではありませんので、事前に計画を立ててください。
• ディストリビューションがパッチ版を提供していない場合や、保守されていないパッケージの修正プログラムがない場合：修正プログラムが存在する可能性もあり、手動で適用したりバックポートしたりすることができます。これにはいくつかの追加作業が必要になりますが、システムにとって重要なパッケージや、公式の修正版がまだ存在しない場合には必要になることがあります。NVDのようなデータベースの脆弱性リンク、ベンダーのフィードやソース、バグレポートの公開情報などをチェックします。修正プログラムが提供されていれば、それを見つけることができるはずです。

18. ループを閉じる

まとめ

• シフトレフトセキュリティ、最初のステップは予防です。
• すべての資産を守ること。
• 組織内で起こっていることをすべて把握し、問題を可能な限り迅速に監視・検出する。
• 攻撃は避けられないので、インシデント対応を計画する。