コンテナセキュリティの基礎：オーケストレーション

このシリーズを初めてお読みになる場合は、最初からご覧になることをおすすめします：
コンテナセキュリティの基礎：概要
コンテナセキュリティの基礎：パイプライン

「Tripwireの2019年コンテナセキュリティの現状」によると、現在、本番環境で100個を超えるコンテナを運用している組織は、約3分の1（32%）です。500個を超えるコンテナを運用している組織は13%と少なく、積極的に導入している組織の6%は、現在1,000個を超えるコンテナを管理しています。大規模にコンテナを運用している組織のうち、運用を支援するオーケストレーションシステムを使用していない組織はほとんどありません。

コンテナセキュリティのオーケストレーション層は、コンテナの日常的な運用を担う環境に重点を置いています。現在入手可能なデータによると、コンテナを使用している場合、ほぼ間違いなくKubernetesをオーケストレーターとして活用しています。

他のオーケストレーターも存在しますが、その多くはKubernetesに由来するコンポーネントや概念を活用している点に留意する必要があります。そのため、ここではKubernetesとそのコンポーネントのセキュリティに焦点を当てます。

Kubernetes環境

Kubernetesは、相互に連携する複数の要素で構成されています。セキュリティの確保が難しいのは、関係するコンポーネントが多いだけでなく、それらが相互に作用するためです。APIを介して通信するものもあれば、ホストのファイルシステムを介して通信するものもあります。いずれもオーケストレーション環境への侵入口となる可能性があるため、対策が必要です。

基本的なKubernetes環境

注意が必要な主要コンポーネントの概要：

• API ServerとKubelet
• Pod
• Etcd

つまり、コーヒーでも用意してください。読み終えるまでには、もう少し時間がかかります。

1. 認証は必須

鋭い読者なら、どこかで聞いた話だと気付くでしょう。「ドアに鍵をかける」とも呼ばれるセキュリティルール2として耳にしたことがあるかもしれません。見過ごされがちなため、今後も繰り返し取り上げる共通のテーマです。強力な認証は欠かせません。実際、コンテナに関する不適切なセキュリティ対策に起因するセキュリティインシデントは増え続けています。その一般的な原因の1つが、認証を使用していないことです。特に、パブリッククラウドにデプロイする場合によく見られます。

強力な認証情報を必須とし、頻繁にローテーションしてください。セキュリティで保護されていないコンソールからAPIサーバーへのアクセスを許すと、オーケストレーション環境全体を制御される可能性があるため、致命的な事態につながりかねません。これには、Podのデプロイ、構成の変更、コンテナの停止と起動が含まれます。Kubernetes環境では、APIサーバーはすべてを支配する「唯一のAPI」です。悪意のある攻撃者の手に渡らないようにする必要があります。

APIサーバーとKubeletを保護する方法
これらの推奨事項は、現行のKubernetes認可モデルに基づいている点に注意してください。使用しているバージョンの最新ドキュメントを必ず確認してください。

• すべての通信でmTLSを有効化
  - サービスごとに専用のCAを用意する（k8s、etcd、アプリケーション）
  - 証明書をローテーションし、ディスク上の秘密鍵のアクセス権限に注意する
  
• セキュアなアドレスにのみバインドする
  - API設定の「insecure-bind-address」と「insecure-port」に注意する
  - _すべて_のサービス（SSH、Vault、etcd）に適用する
  
• 「Anonymous Auth」を無効化
  - 「Anonymous auth」は適切な設定だと思いますか？
  - 1.5以降はデフォルトで無効です。「--anonymous-auth=True」で手動で有効化できます
  
• 認可を有効化
  - 「--authorization-mode=AlwaysAllow」は使用しないでください
  - API Serverには「--authorization-mode=RBAC,Node」を設定してください
  - Kubeletには「--authorization-mode=Webhook」を設定してください
  - Kubeletを制限し、自身のノード上のリソースにのみアクセスできるようにしてください。
  

これらの推奨事項は、現行のKubernetes認可モデルに基づいている点にご注意ください。必ず、ご使用のバージョンに対応する最新のドキュメントを参照してください。

• Kubernetes認可リファレンス
• Kubeletの認証と認可に関するリファレンス

2. Podと権限

Podはコンテナの集合です。Kubernetesを構成する最小単位であり、Container Network Interface（CNI）プラグインによっては、デフォルトですべてのPodが相互に通信できる場合があります。一部のCNIプラグインでは、「ネットワークポリシー」を使用して、このデフォルトの動作に制限を設けることができます。Podは、物理サーバーに相当する複数のKubernetesノードに分散してスケジュールされる可能性があるため、この点は重要です。また、Podは一般に、秘密鍵、認証トークン、その他の機密情報を含むSecretをマウントします。これが「Secret」と呼ばれる理由です。

つまり、Podのセキュリティにはいくつかの懸念があります。F5では、脅威モデリングを開始する際、常にPodが侵害されていることを前提とします。これは、Podがアプリケーションワークロードのデプロイ先だからです。アプリケーションワークロードは信頼できないアクセスにさらされる可能性が最も高いため、侵害の起点となる可能性も最も高くなります。この前提に基づき、潜在的な脅威の緩和方法を計画するために、4つの基本的な問いを検討します。

1. 攻撃者が1つのPodにアクセスできる場合、他のPodに対して何を閲覧または実行できるでしょうか？
2. 攻撃者はクラスター内の他のサービスにアクセスできますか？
3. 自動マウントされるシークレットは何ですか？
4. Podのサービスアカウントにはどのような権限が付与されていますか？

これらの質問への回答から、攻撃者がクラスター内のPodにアクセスした場合に悪用される可能性のあるリスクが明らかになります。Pod侵害の脅威を軽減するには、構成オプション、権限制御、システムレベルの制限を組み合わせた多面的なアプローチが必要です。複数のPodは同じ（物理または仮想）ノードにデプロイできるため、通常はLinux OSであるオペレーティングシステムへのアクセスを共有する点に注意してください。

Podの脅威を軽減する方法
Kubernetesには、Podの機密性に関わる側面を制御するPod Security Policyリソースが含まれています。これにより、オペレーターは、Podがシステムへの受け入れを許可されるために満たすべき動作条件を定義し、PodのSecurity Contextにベースラインを適用できます。デフォルト設定がセキュアであると決めつけないでください。Podの脅威から保護するため、セキュアなベースラインを実装し、想定どおりであることを確認してください。

Pod Security Policyの具体的なオプションでは、以下の項目に対処する必要があります。

• 特権コンテナを使用しない
  • kube-apiおよび／またはkubeletで「—allow-privileged」設定を確認する
  • Pod仕様で「privileged: true」を探します。
  • 「--allow-privileged=false」を使用してセキュリティリスクを軽減する
• Dockerのデフォルトのコンテナユーザーはrootです
  • ワークロードをrootとして実行しないでください
  • Pod Security Policyでは、「runAsUser」、「runAsGroup」、「runAsNonRoot: true」を使用できます
  • 同様のオプションをDockerfileで定義できます
• コンテナ内での権限昇格を禁止
  • 「allowPrivilegeEscalation: false」
• SELinuxまたはAppArmorを使用
  • SELinuxはMulti Category Securityを使用して、コンテナを相互に隔離します
  • 有効のままにして、拒否を1つずつ解消します
  • 無効化するか、許可モードに変更すると、セキュリティが大幅に低下します
• シンボリックリンク／エントリーポイント攻撃を防止
  • 攻撃者は、エントリーポイントのバイナリを上書きしたり、不正なシンボリックリンクを作成したりできます
  • 「readOnlyRootFilesystem: true」を設定して、これを回避します
• host*構成オプションを使用しない
  • ホストリソースにアクセスできる攻撃者は、ホストや隣接するコンテナへ侵害をさらに拡大する可能性が高くなります
  • hostPID、hostIPC、hostNetwork、hostPortsなどのオプションは使用しないでください
• 読み取り専用のhostPathマウント
  • ホストへの読み書きを設定する必要がある場合は、デプロイ時に十分注意し、決してデフォルトの運用にしないでください
  • 攻撃を防ぐため、すべてのallowedHostPathsで「readOnly」を使用する
• Seccompプロファイル
  • 許可するシステムコールを制限して脅威対象領域を縮小
  • Docker defaultにより一部は削減されますが、汎用プロファイルです
  • アプリケーション固有のプロファイルが、セキュリティ上のメリットを最大限に高めます

3. Etcd

Etcdは、構成情報とシークレットを保存するストアです。ここが侵害されると、機密データの抽出や悪意のあるデータの挿入が可能になるおそれがあります。いずれも望ましくありません。etcdへの脅威を軽減するには、アクセスを制御する必要があります。その最善の方法は、mTLSを適用することです。Kubernetesでは、シークレットがetcdにbase64エンコード形式で保存されます。機密性の高いシークレットを保存する際に、より強力な保護オプションを利用するには、アルファ機能の「encryption provider」の使用、またはHashiCorp Vaultの使用を検討してください。

シリーズの次の記事を読む：
コンテナセキュリティの基礎：ワークロード