Kubernetesの脅威モデル

脅威分析の目的は下記参照。

参考

Microsoft 

NCC

外部からの攻撃者

• 脅威の主体

クラスタ上で実行されているアプリケーションや管理ポートにネットワーク経由でアクセスできることを除けば、クラスタへのアクセス権を持たない人々。

• 対策

管理サービス（APIサーバー、kubelet、etcdなど）が、認証制御を行わずに信頼されていないネットワークにさらされないようにする。

悪意のあるコンテナ

• 脅威の主体

攻撃者は、（何らかのアプリケーションの脆弱性を通じて）1つのコンテナにアクセスし、そのアクセスを拡大してクラスタ全体を乗っ取ろうとします。

• 対策

クラスタネットワーク上のすべての管理ポートで、すべてのユーザーに認証が必要であることを確認します。
サービスアカウントがコンテナにマウントされていないか、制限された権限（クラスタ管理者ではない）であることを確認します。
ネットワークポリシーを使用して、ネームスペースとポッド間のアクセスを制限します。

悪意のあるユーザー／危害を加えられたユーザー

• 　脅威の主体

攻撃者は、Kubernetes APIに対してコマンドを実行するための有効な認証情報と、ネットワークアクセスを持っています。

• 対策

　RBACポリシーがすべてのユーザーに適用されており、クラスタリソースへの「最小特権」のアクセスを提供する。
　ポッドセキュリティポリシーがすべてのユーザーに適用されており、特権コンテナなどの高リスクアイテムに特に注意して、作成可能なポッドの権限を制限する。

CNCF

 一般的なKubernetesクラスタに対して実施した詳細な脅威モデル演習の文書と成果を発表しました。この作業の目的は、プラットフォームに共通する攻撃ベクトルを特定し、攻撃者が特定の目標を達成するためにKubernetes内の構成上の脆弱性をどのように利用するかを確認するためのチェックリストとして使用できる、脅威と緩和策に関する詳細な見解を提供することでした。

具体的には、STRIDE手法を用いてKubernetesアーキテクチャの各コンポーネントを分析し、プラットフォーム内の信頼境界における潜在的なセキュリティ問題を特定しました。

Attack Vector	Description
Service Token	デフォルトでは、サービストークンが各ポッドに自動的にマウントされます。コンテナが侵害された場合、攻撃者はそれらの認証情報を使用して悪用するメカニズムを提供することになります。 ここでは、厳格なRBACポリシーと、サービストークンの自動マウントを無効にすることが重要な軽減策となります。
Compromised Container	クラスタ内の主要な拠点が、攻撃者にとってのリモート実行ポイントとなるからです。前述のサービストークン攻撃以外にも、注目すべき攻撃ベクターとして、実行中のすべてのコンテナに対してコントロールプレーンをデフォルトのネットワークで公開することが挙げられます。
Network Endpoints	各Kubernetesエンドポイントは、内部の悪意のあるアクターから保護され、容易な攻撃ベクトルを防ぐ必要があります。攻撃者がコンテナを侵害することができた場合、ポッドのネットワークポリシーが許せば、エンドポイントへのアクセスが可能になることに注意してください。
Denial of Service	1.14のリリースまでは、サービス拒否攻撃に対する緩和策はほとんどありませんでした。
RBAC Issues	攻撃ベクターの多くは、RBACポリシーの設定ミスに依存しています。 対策としては、このようなポリシーを検証するための自動化されたツールが必要です。

Attack Trees

ボトムアップアプローチ

このアプローチでは、目標を達成するために、Kubernetesプラットフォーム全体のエントリーポイントを示します。セキュリティコントロールと標準を脅威に対応させ、その適用範囲を理解するのに役立ちます。

シナリオ・アプローチ

シナリオベースのビューで、特定のシナリオで攻撃者に開かれている攻撃ベクターを特定します。このアプローチは、最初のアプローチの詳細の多くを活用しているが、より現実的な形で、より一般的な攻撃ベクターに焦点を当てるために使用できる。

Attack Tree	Approach	Description
Malicious Code Execution	Bottom Up	この攻撃ツリーの目的は、クラスター上で悪意のあるコードを実行することです。最初の足場は、主に、コンテナへのアクセスを提供する侵害されたアプリケーションを介して行われます。 攻撃者がコンテナにアクセスできるようになると、次のステップとして、環境に悪意のあるコードを追加でロードするようになります。また、イメージプルシークレットを取得できた場合、攻撃者がリポジトリをポイズンしてそこから悪意のあるコードを配布する可能性もあります。
Establish Persistence	Bottom Up	このツリーの目的は、攻撃者がクラスター内で持続性を獲得するためのさまざまな方法を発見し、その持続性を評価することです。 一方、2つ目のブランチは、攻撃者がコンテナにアクセスし、設定ミスを利用して、コンテナ/ポッド/ノードの再起動にも耐えうる持続性を確立するという脅威に焦点を当てています。
Access Sensitive Data	Bottom Up	主なアプローチは、RBAC権限の設定ミスを利用して、クラスターから秘密データを直接読み取ることができることです。その他にも、ログに保存された機密データの閲覧や、ネットワークトラフィックの盗聴などがあります。
Denial Of Service	Bottom Up	このツリーでは、攻撃者がクラスターにサービス拒否攻撃を仕掛けるためのアプローチを検討します。 1つ目のアプローチは、コンテナを侵害するシナリオで、攻撃者がクラスタのリソースを使い切って内部からDOS攻撃を試みる場合です。 2つ目のアプローチは、クラスターのコントロールプレーンにネットワークアクセスできる攻撃者に焦点を当て、適切なエンドポイントでネットワークをフラッディングしてリソースを使い切ろうとする可能性があります。
Compromised application leads to foothold in container	Scenario	このシナリオでは、攻撃者がコンテナ内で実行されているアプリケーションを悪用した場合に、攻撃者に開かれる潜在的なベクターについて詳しく説明します。これにより、プログラムやシェルのアクセスメカニズムを介して、コンテナ内でリモートコードが実行されます。
Attacker on the Network	Scenario	このシナリオでは、Kubernetesクラスターをホストするネットワークにアクセスできる内部攻撃者に焦点を当てます。これは、より特権的なユーザーである可能性が高いですが、クラスタに直接アクセスできません。なお、これらの脅威の大部分は、ファイアウォールと適切なKubernetesの設定によって軽減することができます。

Kubernetes Security Audit Working Group

Scope

この脅威モデルの具体的な内容については、6つの制御ファミリーにわたるKubernetesのコンポーネントをレビューしています。

1. Networking
2. Cryptography
3. Authentication
4. Authorization
5. Secrets Management
6. Multi-tenancy

さらに、Kubernetes自体がAPIゲートウェイからコンテナオーケストレーション、ネットワークなどにまたがる大規模なシステムであることを考慮して、8つのコンポーネントを選択し、今回の演習の範囲に含まれるようにしました。

1. kube-apiserver
2. kube-scheduler
3. kube-controller-manager
4. kube-proxy
5. kubelet
6. etcd
7. cloud-controller-manager
8. Container Runtime