序文
コンテナ テクノロジーとオーケストレーション管理は、クラウド ネイティブ エコシステムの 2 つの中心部分であり、前者は実行を担当し、後者は制御と管理を担当し、これらが合わせてクラウド ネイティブ テクノロジーの有機体を構成します。コンテナ オーケストレーション プラットフォームが直面する可能性のあるリスクを分析する例
コンテナ オーケストレーション プラットフォームが直面するリスク
Kubernetes は最も人気のあるクラウド ネイティブの管理およびオーケストレーション システムとして強力な機能を備えていますが、プログラムが非常に複雑でもあります。リスクとプログラムの複雑さの間にはある程度の関係があることはわかっていますが、複雑なシステムのリスクを分析するのは簡単ではありません。
以下は Kubernetes のアーキテクチャ図です。
一般的な Kubernetes クラスターは 1 つのマスター ノードと 3 つのワーカー ノードで構成され、ポッドは CNI プラグイン Flannel を通じて相互に通信します。Kubernetes 独自のシステム ポッド (kube-system 名前空間のポッド) は主にマスター ノードで実行されます。さらに、各ワーカー ノードにはフランネル ポッドと kube-proxy ポッドもあります。すべてのビジネス ポッドはワーカー ノード上の 3 つに分散されます。 。さらに、各ノードには Kubelet サービスがあり、コンテナーの管理を担当します。
実際、オーケストレーション システムとコンテナは完全に独立しているわけではなく、たとえば、Kubernetes クラスター内に YAML 宣言ファイルの形式で Pod を作成する必要がありますが、Pod は論理的な概念にすぎず、実際には次のもので構成されます。 1 つ以上のコンテナ。コンテナの構成、構成は Pod 構成の形式で提供される必要があります
コンテナ オーケストレーション システムが直面するリスクを主に、Kubernetes インターフェイス、ネットワーク、アクセス制御メカニズム、ソフトウェアの脆弱性の 4 つの側面から説明します。
コンテナインフラストラクチャのリスク
Kubernetes 環境では、コンテナ インフラストラクチャが直面するリスクには主に次の点が含まれます。
- 安全でないサードパーティのコンポーネント、激しく拡散する悪意のあるイメージ、非常に漏洩しやすい機密情報に対して、Kubernetes は、一般的な構成と機密情報を別々に保存するために、ConfigMap と Secrets という 2 つのリソースを提供します。
- 安全でないコンテナ アプリケーション、無制限のリソース共有、安全でない構成とマウント
- クラスタネットワークに存在するリスク
- アクセス制御メカニズムのリスク、つまりコンテナ管理プログラム インターフェースのリスク
- コンテナ ソフトウェアの脆弱性
Kubernetes コンポーネント インターフェイスのリスク
Kubernetes には多くのコンポーネントの脆弱性があり、ほとんどのコンポーネントは HTTP または HTTPS に基づく API の形式でサービスを提供します。その中で、日常的に接触することが多いサービスとそのポートを次の表に示します。
| コンポーネント | デフォルトのポート | 説明する |
|---|---|---|
| APIサーバー | 6443 | HTTPS に基づいたセキュアなポート |
| APIサーバー | 8080 | 安全でない HTTP ポート。有効にすることはお勧めしません |
| キュベレット | 10248 | Kubelet の健全性ステータスをチェックするための HTTP ポート |
| キュベレット | 10250 | APIサーバーを提供するためのHTTPSポート |
| ダッシュボード | 8001 | HTTPサービスを提供するポート |
| etcd | 2379 | クライアントとサーバー間の通信用ポート |
| etcd | 2380 | 異なるサーバーインスタンス間の通信用のポート |
次に、これらのサービスのリスク分析を実行します。
APIサーバー
デフォルトでは、API サーバーはポート 8080 と 6443 でサービスを提供します。そのうちポート 8080 は TLS 暗号化なしで HTTP サービスを提供し、このポートに到達するすべてのリクエストはすべての認証および認可モジュールをバイパスします (ただし、入力制御モジュールは承認されます)。このポートは、主にクラスターのテストと初期起動の便宜のために予約されています。
ただし、本番環境がポート 8080 を開くと、ローカル ループバック アドレス (localhost) がバインドされている場合でも、非常に危険です。このポートがインターネットに公開されると、ネットワークに到達可能な攻撃者はこのポートを通じて API サーバーと直接対話し、クラスター全体を制御できます。
対照的に、ポート 6443 は、TLS で暗号化された HTTPS サービスを提供し、受信リクエストが正常に処理されるためには、認証および認可メカニズムを通過する必要があります。認証および認可メカニズムが正しく構成されている場合、ポート 6443 によって提供されるサービスとセキュリティはより高くなります。
ダッシュボード
デフォルトでは、ローカル ポート 8001 経由でダッシュボードにアクセスする前に、Kubectl プロキシを実行する必要があります。ただし、ダッシュボード ポートがホスト ノードに直接マッピングされている場合、または Kubectl プロキシの実行時に追加のアドレス パラメーターが指定されている場合、攻撃者を含むホストにアクセスできるすべてのユーザーがダッシュボードに直接アクセスできます。
kubetcl proxy --address 0.0.0.0 --accept-hosts='^*$'
また、ダッシュボードはデフォルトでログイン認証が必要ですが、ユーザーがダッシュボードの起動パラメータに--enable-skip-loginオプションを追加すると、攻撃者はダッシュボードインターフェースの「スキップ」ボタンを直接クリックして、ログイン認証を行わずに直接入力することができます。ログイン。ダッシュボード
キュベレット
API サーバーは Kubernetes 全体の中枢であり、多数のアプリケーション インターフェイスを RESTful API の形式で提供していることはわかっています。実際、Kubelet は、API サーバーが Kubernetes ノード上のリソースのステータスを取得または変更するために呼び出すための RESTful API サービスも提供します。
デフォルトでは、Kubelet はポート 10250 で API サービスを開き、他のコンポーネントをポート 10248 でリッスンして Kubelet の実行ステータスを確認します。
curl http://IP:10248/healthz
10248 ポート サービスは比較的シンプルで特別なリスクはありませんが、10250 ポートはそうではない可能性があります。デフォルトでは、API サーバーは Kubelet の API にアクセスするときにクライアント証明書を使用する必要があります。これは比較的安全ですが、それでも例外があります。
1) 攻撃者は API サーバーのクライアント証明書を盗み、何らかの方法で Kubelet にアクセスします。
2) Kubelet の --anonymous-auth パラメーターを true に設定し、認証モードを AlwaysAllow に設定します。
上記の状況が発生した場合、ネットワーク攻撃者は Kubelet と直接対話して、Kubelet が配置されているノードを制御する可能性があります。
etcd
Kubernetes クラスタ内の各種リソースとその状態は etcd に保存されており、etcd のデータを読み込む方法があれば、高い権限を取得してクラスタを制御することが可能になります。現在、etcd は起動後、2379 と 2380 の 2 つのポートをリッスンします。前者はクライアント接続に使用され、後者は複数の etcd インスタンス間のピア通信に使用されます。マルチノード クラスターでは、高可用性を実現するために、etcd は複数のノード間の相互通信を実現するためにノード IP (非ローカル IP) を監視することが多く、これにより外部の攻撃者が etcd にアクセスできる可能性があります。
デフォルトでは、2 つのポートによって提供されるサービスにアクセスするには、対応する証明書が必要です (匿名アクセスは禁止されています)。これにより、etcd のセキュリティが保証されます。攻撃者が証明書を盗んだ場合、またはユーザーが匿名アクセスを許可するように etcd を設定した場合、攻撃者は etcd に直接アクセスしてデータを盗む可能性があります。
クラスタネットワークに存在するリスク
クラスター ポッド間の相互通信を実現するには、Kubernetes をインストールしてデプロイした後、多くの場合、追加のネットワーク プラグインをインストールする必要があります。一般的なネットワーク プラグインには、Flannel、Calico、Cilium などが含まれます。
他のネットワーク分離ポリシーとポッド セキュリティ ポリシーがデフォルトで存在しない場合、ポッドは相互に通信でき、ポッドの root ユーザーには CAP_NET_RAW 権限、ネットワーク検出、スニッフィング、サービス拒否、およびマンインザ権限があるため、クラスタ内でミドル攻撃やその他のサイバー攻撃が発生する可能性がある
アクセス制御メカニズムのリスク
Kubernetes のアクセス制御メカニズムは主に、認証メカニズム、認可メカニズム、アドミッション メカニズムの 3 つの部分で構成されており、通常、各部分には 1 つ以上の特定の実装メカニズムから選択できます。アクセス制御が緩すぎると、高い権限を持つアカウントが悪用される可能性があり、Kubernetes 自体や実行中のコンテナに脅威をもたらす可能性があります。また、Kubernetes への不正アクセスが許可されている場合、攻撃者はこれを利用してクラスターに直接アクセスする可能性があります。管理者の権限
修復不可能なソフトウェアの脆弱性
複雑なシステムとして、Kubernetes は当然多くのセキュリティ脆弱性にさらされており、当然、それらも Kubernetes が直面するリスクに属します。
参考：『クラウドネイティブセキュリティ 攻撃と防御の実践とシステム構築』