Kubernetes 制御プラットフォームを保護するための 10 のヒント

翻訳者 |李睿

レビュー |チョンロウ

51CTO 読者成長計画コミュニティ募集、コンサルティングアシスタント (WeChat ID: TTalkxiaozhuli)

調査機関が最近発表した調査レポートによると、回答者の 94% が Kubernetes に関連するセキュリティインシデントを経験したことがあると回答しています。 Kubernetes の脆弱性で最も一般的なのは構成ミスであり、回答者の 70% が報告しました。では、サイバー犯罪者にとって魅力的なターゲットとは何でしょうか? Kubernetes 制御プラットフォーム。

チームは、ノード、マスター、コアコンポーネント、API、および公開ポッドの境界セキュリティを強化する必要があります。そうしないと、既存および潜在的な脆弱性からクラスターを保護できなくなります。ここでは、企業が Kubernetes コントロールプレーンを保護し、導入プロセスをスピードアップするのに役立つ 10 のベストプラクティスを紹介します。

Kubernetes コントロールプレーンのセキュリティを確保するための 10 のヒント

1. Kubernetesのロールベースアクセス制御（RBAC）を使用する

ロールベースのアクセス制御 (RBAC) を使用して、Kubernetes API にアクセスできるユーザーの権限を設定します。 Kubernetes 1.6 以降では、RBAC がデフォルトで有効になっていることがわかります。 Kubernetes は認証コントローラーを集中管理するため、RBAC を有効にすると従来の属性ベースのアクセス制御 (ABAC) を無効にすることができます。

権限を設定するときは、クラスター全体の権限ではなく、名前空間固有の権限を選択します。チームメンバーがデバッグで忙しい場合でも、誰にもクラスター管理者権限を与えないでください。そうしないと、クラスターのセキュリティが侵害される可能性があります。

2. 検疫を実施する

Kubernetes ノードをパブリックインターネットに直接公開しないでください。代わりに、ノードに最適な場所は、企業ネットワークに直接接続されていない別のネットワーク上です。

もう 1 つの重要な分離のベストプラクティスは、Kubernetes の制御トラフィックとデータトラフィックを分離することです。データプラットフォームへのオープンアクセスは制御プラットフォームへのオープンアクセスにつながるため、ユーザーはこれらが同じパイプラインを通過することを望んでいます。

3. デフォルトの名前空間にオブジェクトをデプロイしないようにする

Kubernetes では、名前空間はクラスター内のリソースグループを分離するメカニズムを提供します。したがって、複数のチームやプロジェクトにまたがる多数のユーザーが存在する環境に最適なユースケースです。

指定された名前空間を持たないすべてのオブジェクトは、デフォルトの名前空間を使用することになります。これにより、最も重要なワークロードの近くに悪意のあるコンテナを展開することが容易になります。したがって、デプロイメント内のオブジェクトの名前空間を作成することをお勧めします。

4. 禁止されているタイプを使用しない

NodePort や LoadBalancer などの禁止されたタイプの使用は避けてください。代わりに、サービスは ClusterIP 経由で公開する必要があります。このようにして、クラスターインフラストラクチャコンポーネントが特定の悪意のある行為者によって検出されるのを防ぐことができます。

5. 機密データを暗号化する

Kubernetes の基本的な実装では、機密データはデフォルトでは暗号化されないことをご存知でしたか?ただし、ユーザーが GKE などの Kubernetes マネージドサービスを使用する場合、機密データは保存時に暗号化されます。

機密データを暗号化することが重要なのはなぜですか?キー値ストアを傍受する人は誰でも、クラスター内のすべてのものにアクセスできます。これには、すべてのプレーンテキストのクラスターシークレットが含まれます。したがって、クラスター状態ストレージを暗号化することが、クラスターを静的データの漏洩から保護する最善の方法です。

6. Etcdへの安全なアクセス

Etcd へのアクセスは root 権限と同等です。そのため、これは重要な制御プラットフォームコンポーネントであり、制御プラットフォーム内で最も重要な安全コンポーネントです。

Etcd との通信が暗号化され、クライアントが証明書ベースの認証を使用していることを確認します。攻撃対象領域を制限するには、理想的には API サーバーのみが Etcd にアクセスできる必要があります。

7. コンテナランタイムソケットをコンテナ内にマウントしない

デプロイメントでコンテナーに Container Runtime (CRI) ソケットがマウントされているかどうかを気にする必要があるのはなぜでしょうか? docker.sock、container.sock、crio.sock を使用すると、ネットワーク攻撃者がホストマシンおよび対応するコンテナーランタイムへのルートアクセスを取得する可能性が高くなります。これを回避するには、/var/run/<CRI>.sock hostPath ボリュームを削除します。

8. 読み取り専用のルートファイルシステムなしでコンテナを実行しますか?行動する前に考えよう

コンテナは読み取り専用のルートファイルシステムなしで実行されますか?読み取り専用ファイルシステムを使用すると、悪意のあるバイナリがシステムに書き込まれたり、システムが乗っ取られたりするのを防ぐことができます。 Pod の securityContext 定義で readOnlyRootFilesystem を true に設定すると、コンテナーが読み取り専用ファイルシステムのみを使用するようにすることができます。

9. セキュリティを確保し、Kubernetesコントロールプレーンにアクセスする

多要素認証などの追加のセキュリティ機能については、サードパーティの認証プロバイダーの支援を受けることができます。 Kubernetes コントロールプレーンアクセスを完全に保護するには、API サーバーレベルでユーザーを管理しないようにします。代わりに、AWS ID およびアクセス管理 (IAM) など、クラウドプロバイダーが提供するソリューションを使用してください。クラウドベンダーの IAM にアクセスできない場合は、OpenID Connect (OIDC) と使い慣れたシングルサインオン (SSO) プロバイダーを選択できます。

10. ローリングアップデート戦略を作成する

EKS のセキュリティを確保するには、ローリングアップデート戦略を導入する必要があります。一方、ローリングアップデートでは、増分ポッドアップデートにより、アプリケーションのダウンタイムを最小限に抑えてアップデートを展開できます。

もう 1 つのポイントは、実行時に脆弱性スキャンを実行することです。クラスターはサプライチェーン攻撃のリスクにさらされています。これらに対処するには、継続的インテグレーション (CI)/継続的デリバリー (CD) 中にすべてのデプロイメント成果物をスキャンする場合でも、実際にクラスターに何が入力されるかを理解する必要があります。ここでは、エージェントベースのセキュリティソリューションが「エージェントレス」よりも効果的に機能します。