ブログ

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

  ジョーダン・ゼボール

  ロリ・マクヴィッティ

2019年7月24日公開

このシリーズを初めて読む場合は、最初から始めることをお勧めします。 
コンテナ セキュリティの基礎: 導入
コンテナ セキュリティの基礎: パイプライン

Tripwire の 2019 年コンテナ セキュリティの現状によると、現在、約 3 分の 1 (32%) の組織が 100 を超えるコンテナを本番環境で運用しています。 500 台以上を運用している割合は少数 (13%) です。 そして、本当に熱心な導入者の 6% が現在 1,000 を超えるシステムを管理しています。 オーケストレーション システムを使用せずに大規模にコンテナを運用している組織はほとんどありません。

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

他にもオーケストレーターは存在しますが、そのほとんども Kubernetes から派生したコンポーネントと概念を活用していることに注意することが重要です。 したがって、Kubernetes とそのコンポーネントのセキュリティに焦点を当てます。

Kubernetes 環境

Kubernetes を構成する可動部分は複数あります。 これにより、関係するコンポーネントの数だけでなく、それらのコンポーネントが相互作用する方法によっても、セキュリティを確保することがより困難になります。 一部は API 経由で通信し、その他はホスト ファイル システム経由で通信します。 これらはすべて、対処する必要があるオーケストレーション環境への潜在的なエントリ ポイントです。 

基本的なKubernetes環境

基本的なKubernetes環境

注意が必要なコア コンポーネントの簡単な概要:

  • API サーバーと Kubelet
  • ポッド
  • その他

つまり、コーヒーを一杯飲みながら、これを読み終えるのにもう少し時間がかかるということです。

1. 認証はオプションではありません

賢明な読者なら、これが聞き覚えのある話だと気づくでしょう。 セキュリティルール2、別名 ドアをロックしてください。 これは無視されることが多いため、私たちが繰り返し述べる共通のテーマです。 強力な認証は必須です。 コンテナに関するセキュリティ対策の不備が原因で発生するセキュリティ インシデントの件数が増加し続けていることを私たちは見てきました。 よくある原因の 1 つは、通常、パブリック クラウドに展開されている場合に認証が使用されないことです。

強力な資格情報が必要であり、頻繁にローテーションする必要があります。 API サーバーへのアクセス (セキュリティ保護されていないコンソール経由) は、オーケストレーション環境全体を API サーバー経由で制御できるため、「ゲームオーバー」の状況につながる可能性があります。 つまり、ポッドのデプロイ、構成の変更、コンテナの停止/起動を意味します。 Kubernetes 環境では、API サーバーは「すべてを支配する 1 つの API」であり、悪意のあるユーザーの手に渡らないようにする必要があります。

API サーバーと Kubelet を保護する方法
これらの推奨事項は、現在の Kubernetes 認証モデルに基づいていることに注意することが重要です。 使用しているバージョンの最新のドキュメントを常に参照してください。

  • どこでもmTLSを有効にする
    - サービスごとに専用の CA を用意する (k8s、etcd、applications)
    - 証明書をローテーションし、ディスク上の秘密鍵の権限に注意する
  • 安全なアドレスにのみバインドする
    - API 設定「insecure-bind-address」と「insecure-port」に注意してください
    - これをすべてのサービス（SSH、Vault、etcd）に適用します
  • 「匿名認証」を無効にする
    - 「匿名認証」は良いアイデアだと思いますか?
    - 1.5 以降ではデフォルトで無効になっていますが、手動で「--anonymous-auth=True」で有効にすることができます。
  • 認証を有効にする
    - “--authorization-mode=AlwaysAllow” を使用しないでください
    - API サーバーには「--authorization-mode=RBAC,Node」が必要です
    - Kubelet には「--authorization-mode=Webhook」が必要です
    - Kubelet が自身のノード上のリソースにのみアクセスできるように制限します。

これらの推奨事項は、現在の Kubernetes 認証モデルに基づいていることに注意することが重要です。 常に、使用しているバージョンの最新のドキュメントを参照してください。 

2. ポッドと権限 

ポッドはコンテナの集合です。 これらは最小の Kubernetes コンポーネントであり、Container Network Interface (CNI) プラグインに依存しており、すべてのポッドはデフォルトで相互にアクセスできる可能性があります。 「ネットワーク ポリシー」を使用してこのデフォルトの動作に制限を実装できる CNI プラグインがあります。 ポッドは異なる Kubernetes ノード (物理サーバーに類似) でスケジュールできるため、この点に注意することが重要です。 ポッドは通常、秘密鍵、認証トークン、その他の機密情報などのシークレットもマウントします。 だから「秘密」と呼ばれているのです。

つまり、ポッドとセキュリティに関していくつかの懸念があるということです。 F5 では、脅威のモデル化を開始するときに、常にポッドが侵害されていると想定します。 これは、ポッドがapplicationワークロードがデプロイされる場所であるためです。 applicationワークロードは信頼できないアクセスにさらされる可能性が最も高いため、侵害が発生する可能性が最も高くなります。 この仮定に基づいて、潜在的な脅威を軽減する方法を計画するために尋ねるべき 4 つの基本的な質問が導き出されます。 

  1. 攻撃者は、ポッドへのアクセス権を与えられた他のポッドで何を見たり、何をしたりできますか?
  2. 攻撃者はクラスター内の他のサービスにアクセスできますか?
  3. 自動マウントされるシークレットは何ですか?
  4. ポッド サービス アカウントにはどのような権限が付与されていますか?

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

ポッドの脅威を軽減する方法
Kubernetes には、ポッドの機密部分を制御するポッド セキュリティ ポリシー リソースが含まれています。 これにより、オペレーターは、ポッドがシステムにアクセスできるようにするためにポッドが動作する必要がある条件を定義し、ポッドのセキュリティ コンテキストのベースラインを適用できるようになります。 デフォルトが安全であると決して想定しないでください。 安全なベースラインを実装し、期待値を検証してポッドの脅威から保護します。

Pod セキュリティ ポリシーの特定のオプションは、次の点に対処する必要があります。

  • 特権コンテナを避ける
    • kube-apiおよび/またはkubeletで「—allow-privileged」設定を探します
    • ポッド仕様で「privileged: true」を探します。
    • 「--allow-privileged=false」でセキュリティリスクを軽減
  • Dockerのデフォルトのコンテナユーザーはrootです
    • いかなるワークロードもルートとして実行しないでください
    • Podセキュリティポリシーでは、「runAsUser」、「runAsGroup」、「runAsNonRoot: true」を使用できます。
    • 同様のオプションはDockerfileでも定義できます
  • コンテナ内での権限昇格を禁止する
    • 「allowPrivilegeEscalation: false」
  • SELinux / AppArmorを使用する
    • SELinuxはマルチカテゴリーセキュリティを利用してコンテナ同士を隔離する。
    • 有効のままにして、拒否に対処する
    • 許可モードを無効にしたり変更したりすると、セキュリティが大幅に低下します。
  • Symリンク/エントリポイント攻撃を防ぐ
    • 攻撃者はエントリポイントバイナリを上書きしたり、不正なシンボリックリンクを作成したりできる
    • 「readOnlyRootFilesystem: true」を設定することでこれを回避する
  • ホスト*構成オプションを避ける
    • ホストリソースにアクセスできる攻撃者は、ホストや隣接するコンテナへの侵入をさらに進める可能性が高くなります。
    • hostPID、hostIPC、hostNetwork、hostPortsなどのオプションは避けてください。
  • 読み取り専用ホストパスマウント
    • ホストへの読み取り/書き込みを構成する必要がある場合は、展開に注意し、これをデフォルトのプラクティスにしないでください。
    • 攻撃を回避するために、すべての allowedHostPaths で「readOnly」を使用します。
  • Seccomp プロファイル
    • 許可されたシステムコールを制限することで脅威の対象となる領域を減らす
    • Dockerのデフォルトではいくらか削減されますが、これは一般的なプロファイルです
    • application固有のプロファイルは最大のセキュリティ上の利点を提供します

3. その他

Etcd は構成と秘密を保存する場所です。 ここで侵害が発生すると、機密データの抽出や悪意のあるデータの挿入が可能になります。 どちらも良くない。 etcd への脅威を軽減するには、アクセスを制御する必要があります。 これは、 mTLS を適用することで最も効果的に実現できます。 シークレットは、Kubernetes によって base64 でエンコードされてetcdに保存されます。 機密性の高い秘密を保存する際のより強力なオプションとして、アルファ機能「暗号化プロバイダー」の使用を検討するか、HashiCorp Vault の使用を検討してください。

シリーズの次のブログをお読みください: 
コンテナ セキュリティの基礎: 作業負荷