Kubernetes の 5 つのセキュリティ プラクティス

[[343801]]

Kubernetes は登場してからまだ 6 年も経っていませんが、すでにみんなのお気に入りのコンテナ オーケストレーターになっています。クラウドおよびインフラストラクチャ監視会社 Datadog は、Kubernetes がコンテナ市場を支配していることを発見しました。「コンテナを実行している Datadog の顧客の約 45% が Kubernetes を使用しています。」 Marathon や Docker swarm などの他のコンテナ オーケストレーターは廃止されました。

Kubernetes はパブリッククラウドでより人気があります。たとえば、Datadog によれば、「Azure でコンテナーを実行している Datadog の顧客の約 80% が現在 Kubernetes を使用しています。」 Amazon Web Services (AWS) では、Datadog の人気は過去 2 年間で 2 倍の 45% に達しました。

人気が高ければ高いほど、危険も大きくなります。 Windows ユーザーは、プログラムの人気が高まるほど、攻撃に対して脆弱になることをよく知っています。 Kubernetes についても同様です。使用している場合は保護する必要があります。

しかし、それは簡単ではありません。

Kubernetes の管理組織である Cloud Native Computing Foundation (CNCF) は最近、Trail of Bits と Atredis のパートナーに対してセキュリティ監査を実施しました。 Bits のレポートによると、Kubernetes は構成や展開が簡単ではなく、一部のコンポーネントのデフォルト設定がわかりにくく、運用管理や暗黙的に設計されたセキュリティ管理が不足しているため、多くのセキュリティ上の問題があるとのことです。 ”

これは、それが本当に簡単ではないことを示しています。

しかし、私たちは挑戦しなければなりません。 Kubernetes を保護するための 5 つの方法をご紹介します。

1. コンテナ自体が安全であることを確認する

コンテナが壊れている場合、Kubernetes を保護してもメリットはありません。オープンソース セキュリティ企業 Snyk は、2019 年に最も人気のある 10 個の Docker イメージを分析しました。その結果、すべてのイメージに脆弱なシステム ライブラリが含まれていることが判明しました。

VMware の副社長兼最高オープンソース責任者である Dirk Hohndel 氏は、2019 年の Open Source Leadership Summit で次のように述べています。「コンテナのパッケージ形式は、Windows の .exe や macOS の .dmg に似ており、基本的にすべての依存関係を含む完全なファイル システムを出荷します。コンテナにこれらの依存関係が含まれるようになったため、それらのバイナリが何であるか、どのように生成されたか、どこから来たかに注意する必要があります。」

つまり、コンテナを管理のために Kubernetes にデプロイする前に、コンテナの内容が信頼できるものであることを確認する必要があります。そうしないと、最も一般的なコンピュータの問題の 1 つである、ガベージ コレクションの制御不能 (GIGO) が発生します。したがって、すべての本番コンテナで潜在的なセキュリティ問題をチェックする以外に選択肢はありません。

はい、痛いです。セキュリティは簡単だと言った人は誰もいません。

2. コンテナのLinuxカーネルをロックダウンする

ここからさらに困難になるだけだ。コンテナが安全であることを保証するだけでなく、すべてのコンテナが単一の Linux カーネル上で実行されるため、カーネルが可能な限り安全であることを保証することが理にかなっています。さらに、カーネルを保護するためのセキュリティ構成には、AppArmor または SELinux を使用することをお勧めします。

ただし、これらの複雑な構成により、ユーザー制御、プログラム管理、ファイル アクセス、およびシステム メンテナンスが制限されます。彼らはこれを Linux セキュリティ モジュールとして実装し、Linux に強制アクセス制御 (MAC) アーキテクチャを課しました。これは、Linux の組み込みセキュリティ モデル (明示的に禁止されていない限りすべてを許可する) とはまったく異なるセキュリティ アプローチ (明示的に許可されていない限りすべてを制限する) です。

多くのシステム管理者は、両方を正しく設定できません。さらに悪いことに、誤って設定した場合、単なる再構成プロセスでは済みません。正しく設定しないと、Linux システムがフリーズしてしまい、再調整が必要になります。あるいは、正しく構成されていると思っていても、実際にはコンテナは以前と同様に攻撃に対して脆弱なままである可​​能性があります。

正しく安全な構成には、オペレーターのかなりの時間と専門知識が必要です。 AppArmor または SELinux によって保護されたカーネル上でアプリケーションを実行すると、問題が発生する可能性があります。ほとんどのプログラムは、基盤となるオペレーティング システムのセキュリティ対策を考慮しています。これらの保護されたカーネルではこれは許可されません。

これらの方法のいずれかが面倒すぎる場合は、カーネルがカーネル モジュールを自動的にロードしないようにすることで、ある程度の保護を得ることができます。たとえば、権限のないプロセスでもネットワーク プロトコルに関連する一部のカーネル モジュールを強制的にロードできるため、特定のネットワーク ソケットを作成するだけで、問題のあるモジュールをブロックするルールを追加できます。禁止モジュール設定ファイルを使用してこれを実行できます。

 /etc/modprobe.d/kubernetes-blacklist.conf

ファイルに構成指示を追加することを忘れないでください。次に例を示します。

#SCTP はほとんどの Kubernetes クラスターでは使用されておらず、脆弱性があります。

ただし、最善の方法は、AppArmor または SELinux をインストールすることです。

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

Kubernetes 1.8 以降では、RBAC を使用してユーザーが実行できる操作を制御できます。これは重要です。何十ものインスタンスとクラスターで実行されているユーザーにサービスを提供しようとするのは大変なことです。ゼロトラスト セキュリティ アプローチである RBAC を使用すると、ユーザーとコンポーネント (アプリケーションやノードなど) には、タスクを完了するために必要な権限のみが付与されます。

RBAC は、アプリケーション プログラミング インターフェイス (API) レベルで動作します。この方法では、承認者自体が使用されていない場合でも、RBAC ルールによってユーザーがロックアウトされます。 RBAC は、ユーザーがロールまたはロール バインディングを編集して自分自身にさらに権限を付与することを防ぎます。

デフォルトでは、部外者もブロックされます。 RBAC ポリシーは、コントロール プレーン コンポーネント、ノード、およびコントローラーにスコープ指定されたアクセス許可を付与します。ただし、これは重要なことですが、kube-system 名前空間の外部のサービス アカウントには権限が付与されません。

Kubernetes の管理を容易にするために、RBAC は事前定義されたロールを提供します。これにより、開発者、オペレーター、クラスター管理者には必要な権限のみが与えられ、不要な権限は与えられなくなります。

このシステムでは、クラスター管理者の役割は Unix および Linux のスーパーユーザーに相当します。クラスター管理者は、任意のクラスター リソースを作成、編集、または削除できます。言うまでもなく、クラスター管理者ロールのアクセス権限は慎重に保護する必要があります。

4. 秘密を守ることの大変さ

Kubernetes Secrets オブジェクトには、パスワード、OAuth トークン、SSH キーなどの機密要素が含まれています。つまり、これらは Kubernetes クラスターの鍵となります。彼らを守らなければなりません。

Kubernetes は、API にアクセスするためのシークレットを自動的に作成し、それらを使用するようにポッドを変更します。ただし、秘密情報 (Pod がデータベースにアクセスするために必要なユーザー名やパスワードなど) は、ユーザーが管理および保護します。

簡単ですよね？残念ながら、Kubernetes シークレットには多くのセキュリティ上の脆弱性が組み込まれています。当局が挙げた脆弱性のリストは、ただただ恐ろしい。

• API サーバーでは、秘密データは ETCD に保存され、Kubernetes はデフォルトで分散キー値ストレージを使用します。デフォルトでは、etcd データは暗号化されないため、シークレットも暗号化されません。したがって、保存時の暗号化を有効にし、etcd アクセスを管理者ユーザーに制限する必要があります。
• 多くのユーザーは機密情報を JSON または YAML ファイルに保存します。ここで、機密データは base64 としてエンコードされます (暗号化されません)。つまり、構成ファイルを共有したり、コード リポジトリにコミットしたりすると、他のユーザーがすべてのシークレットを読み取ることができるようになります。
• アプリケーションがシークレットを使用すると、そのシークレットをログに記録したり、信頼できない相手に送信したりすることはできなくなります。
• シークレットを使用するポッドを作成できるユーザーは、シークレットの値も確認できます。 API サーバー ポリシーでそのユーザーに読み取りが許可されていない場合でも、ユーザーはシークレットを公開する Pod を実行できます。
• 現在、任意のノードでルート権限を持つユーザーは、kubelet になりすまして API サーバーから任意のシークレットを読み取ることができます。これは実際に機能です。秘密を必要とするノードとのみ秘密を共有することで、ルート攻撃が単一のノードに与える可能性のある損害をその 1 つのノードに限定できるという考え方です。

この状況は悪いです。秘密を暗号化することで、この問題を常に軽減できます。可能であれば、このシークレットをイメージまたはポッドとは別に保管する必要があります。 1 つのアプローチは、プロセスを個別のコンテナーに分割することです。たとえば、アプリケーションをフロントエンド コンテナーとバックエンド コンテナーに分離できます。バックエンドは秘密鍵シークレットを保持し、フロントエンドからの署名要求に応答します。

セキュリティ管理者と Kubernetes 管理者の両方でない限り、シークレットを保護するにはサードパーティのシークレット ツールを使用する必要があります。これらには、AWS Secrets Manager、Google Cloud Platform KMS、パブリッククラウド用の Azure Key Vault が含まれます。また、Hashicorp Vault、Cyber​​Ark/Conjur、Confidant、Aqua Security Kubernetes Security for the Enterprise などのプログラムもあります。

5. オンラインで安全を確保する

上記のように、etcd へのアクセスを許可することは非常に危険です。 Kubernetes セキュリティ企業 ControlPlane の共同設立者である Andrew Martin 氏は、Kubernetes 自身のブログで次のように書いています。「API サーバーの etcd への書き込みアクセスは、クラスター全体のルート権限を取得することと同等であり、読み取りアクセスでさえも簡単に権限を昇格させることができます。」

そのため、Martin 氏は次のように推奨しています。「etcd はピアおよびクライアント TLS 証明書を使用して構成し、専用ノードにデプロイする必要があります。ワーカー ノードから秘密鍵が盗まれて使用されるのを防ぐために、クラスターはファイアウォールを介して API サーバーに接続することもできます。」

ネットワーク保護が必要なのは etcd だけではありません。 Kubernetes は完全に API 駆動型であるため、すべての内部クラスター通信はデフォルトで TLS を使用して暗号化されます。

しかし、それだけでは十分ではありません。デフォルトでは、Kubernetes Pod はあらゆるソースからのトラフィックを受け入れます。繰り返しますが、「あらゆる情報源」です。 Pod はネットワーク接続に対してオープンですが、安全ではありません。ポッドがクラスター内および外部リソースと通信する方法を安全​​に定義するネットワーク ポリシーを決定するのはあなた次第です。

これは、ネットワーク ポリシー コントローラーをサポートするネットワーク プラグインを追加することで実現できます。このようなコントローラがないと、設定したネットワーク ポリシーは有効になりません。残念ながら、Kubernetes には、公式のデフォルト、またはデフォルトで推奨されるネットワーク ポリシー コントローラーがありません。代わりに、Calico、Cilium、Kube-router、Romana、Weave Net などのサードパーティ製プラグインを使用する必要があります。とにかく私のお気に入りはカリコです。

「デフォルトですべて拒否」ネットワーク ポリシーから始めることをお勧めします。これにより、他のネットワーク ポリシー ルールで明示的に許可した接続のみが許可されます。ネットワーク ポリシーは名前空間に設定されるため、名前空間ごとにネットワーク ポリシーを設定する必要があります。

セットアップが完了したら、適切なネットワーク アクセス ルールを許可できるようになります。詳細については、[Kubernetes ネットワーク ポリシー レシピ] (https://github.com/ahmetb/kubernetes-network-policy-recipes) を参照してください。

Kubernetes のセキュリティを確保するのは簡単な作業ではありません。

冒頭で述べたように、Kubernetes のセキュリティを確保するのは確かに簡単な作業ではありません。今のところ、あなたも私の意見にかなり同意していただいていると思います。

Kubernetes は最初から簡単に導入できるように設計されています。残念ながら、これは設計上安全ではないことも意味します。つまり、セキュリティを追加するかどうかは完全にあなた次第です。幸いなことに、セキュリティを追加すると、Kubernetes クラスターはより実稼働に適したものになります。

この記事では、Kubernetes セキュリティに関して対処する必要がある最も重要な問題のみを取り上げます。もちろん、他にも多くの問題があります。しかし、この仕事がいかに重要であるかを理解していただくために、十分なアイデアを提供できたことを心から願っています。そして、今すぐ Kubernetes クラスターの保護を開始する必要があります。そうしないと、ハッカーはためらうことなく、会社の重要なシステムを危険にさらしていることを指摘するでしょう。

翻訳者：朱翔

元記事: https://www.idginsiderpro.com/article/3571466/the-five-best-kubernetes-security-practices.html