Kubernetes クラスターの穴を修正します。 DevOpsConf のレポートとトランスクリプト

サウスブリッジ ソリューション アーキテクトであり、Slurm 教師である Pavel Selivanov 氏が、DevOpsConf 2019 でプレゼンテーションを行いました。この講演は、Kubernetes の詳細コース「Slurm Mega」のトピックの XNUMX つです。

Slurm Basic: Kubernetes の概要 18月20日からXNUMX日までモスクワで開催される。
Slurm Mega: Kubernetes の内部を見る — モスクワ、22月24日からXNUMX日。
Slurm Online: 両方の Kubernetes コース いつでも利用可能です。

カットの下はレポートの転写です。

同業者の皆様、そして彼らに共感してくださる皆様、こんにちは。 今日は安全性についてお話します。

今日はホールに警備員がたくさんいるようだ。 私がセキュリティの世界の用語を使用した場合、お客様の慣習とまったく異なる場合は、あらかじめお詫び申し上げます。

たまたま、約 XNUMX か月前に、パブリック Kubernetes クラスターを XNUMX つ見つけました。 パブリックとは、n 番目の名前空間が存在することを意味し、これらの名前空間には、名前空間内で分離されたユーザーが存在します。 これらのユーザーはすべて異なる会社に属しています。 さて、このクラスターは CDN として使用されることが想定されていました。 つまり、クラスターが提供され、そこにユーザーが提供され、そこにある名前空間に移動して、フロントをデプロイします。

私の前の会社はそのようなサービスを販売しようとしていました。 そして、このソリューションが適切かどうかを確認するためにクラスターを調査するように依頼されました。

このクラスターに来ました。 私に与えられた権限と名前空間は限られていました。 そこにいる人たちは安全とは何かを理解していました。 彼らは、Kubernetes のロールベースのアクセス制御 (RBAC) について読みました。そして、デプロイメントとは別にポッドを起動できないように、それをねじ曲げました。 デプロイメントなしでポッドを起動することで解決しようとしていた問題は覚えていませんが、本当にポッドだけを起動したかったのです。 幸運を祈って、クラスター内で自分にどのような権限があるのか​​、何ができるのか、何ができないのか、クラスターで何が台無しになっているのかを確認することにしました。 同時に、RBAC で何が間違って設定されているかについても説明します。

たまたま、XNUMX 分以内にクラスターの管理者を受け取り、隣接するすべての名前空間を調べ、すでにサービスを購入して展開している企業の稼働中の運用フロントを確認しました。 私は誰かの前に行き、メインページに悪口を載せるのをかろうじて止められませんでした。

私がどのようにこれを行ったか、そしてこれから身を守る方法を例を挙げて説明します。

でもその前に、自己紹介をさせてください。 私の名前はパベル・セリバノフです。 私はサウスブリッジの建築家です。 私は Kubernetes、DevOps、その他あらゆる種類の高度なことを理解しています。 サウスブリッジのエンジニアと私はこれらすべてを構築しており、私はコンサルティングを行っています。

私たちの主な活動に加えて、最近では Slurms というプロジェクトを立ち上げました。 私たちは、Kubernetes を使用する能力を一般の人に少しでも提供し、K8 を使用する方法を他の人に教えようとしています。

今日は何について話しましょうか？ レポートのテーマは明らかです。Kubernetes クラスターのセキュリティに関するものです。 しかし、このトピックは非常に大きなものであるため、私が絶対に話さないことをすぐに明確にしたいと思います。 インターネット上ですでに何百回も使用されている陳腐な用語については話しません。 あらゆる種類の RBAC と証明書。

Kubernetes クラスターのセキュリティに関して私と同僚が苦しんでいることについて話します。 これらの問題は、Kubernetes クラスターを提供するプロバイダーの間でも、当社に来るクライアントの間でも発生しています。 さらには、他のコンサルティング管理会社から当社にやって来るクライアントからも同様です。 つまり、悲劇の規模は実際には非常に大きいのです。

今日お話しするポイントは文字通り次の XNUMX つです。

1. ユーザー権限とポッド権限。 ユーザー権限とポッド権限は同じものではありません。
2. クラスターに関する情報を収集します。 このクラスターに対する特別な権限がなくても、クラスターから必要な情報をすべて収集できることを示します。
3. クラスターに対する DoS 攻撃。 情報が集まらない場合はいずれにしてもクラスターを入れることになります。 クラスタ制御要素に対する DoS 攻撃について説明します。

私が言及するもう XNUMX つの一般的なことは、私がこれらすべてをテストした結果であり、すべてが機能することは間違いなく言えます。

Kubespray を使用した Kubernetes クラスターのインストールを基本とします。 知らない人もいるかもしれませんが、これは実際には Ansible のロールのセットです。 私たちは仕事で常にそれを使用しています。 良い点は、どこにでも転がせることです。鉄片の上や雲のどこかに転がすこともできます。 原則として、XNUMX つのインストール方法がすべてに適用されます。

このクラスターには Kubernetes v1.14.5 が含まれます。 これから考察する Cube クラスター全体は名前空間に分割され、各名前空間は別個のチームに属し、このチームのメンバーは各名前空間にアクセスできます。 異なる名前空間に移動することはできず、自分自身の名前空間にのみ移動します。 ただし、クラスター全体に対する権限を持つ特定の管理者アカウントが存在します。

最初にクラスターに対する管理者権限を取得することを約束しました。 Kubernetes クラスターを破壊するために特別に準備されたポッドが必要です。 必要なのは、それを Kubernetes クラスターに適用することだけです。

kubectl apply -f pod.yaml

このポッドは、Kubernetes クラスターのマスターの 98 つに到着します。 この後、クラスターは admin.conf というファイルを喜んで返します。 Cube では、このファイルにすべての管理者証明書が保存され、同時にクラスター API が構成されます。 これにより、Kubernetes クラスターの XNUMX% に管理者アクセスを取得することがいかに簡単になるかがわかります。

繰り返しますが、このポッドはクラスター内の XNUMX 人の開発者によって作成され、その開発者は自分の提案を XNUMX つの小さな名前空間にデプロイするアクセス権を持ち、すべて RBAC によって制限されています。 彼には何の権利もありませんでした。 しかし、それでも証明書は返還されました。

そして今度は特別に準備されたポッドについてです。 任意の画像に対して実行します。 debian:jessie を例にしてみましょう。

こんなものがあります。

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

寛容とは何ですか？ Kubernetes クラスター内のマスターは通常、テイントと呼ばれるものでマークされます。 そして、この「感染」の本質は、ポッドをマスターノードに割り当てることができないということです。 しかし、ポッドに「感染」に対する耐性があることをわざわざ示す人は誰もいません。 許容セクションでは、一部のノードに NoSchedule がある場合、そのノードはそのような感染に対して耐性があり、問題はないと述べているだけです。

さらに、私たちのアンダーは寛容であるだけでなく、マスターを特にターゲットにしたいと考えていると言います。 なぜなら、マスターは私たちが必要とする最もおいしいもの、つまりすべての証明書を持っているからです。 したがって、nodeSelector と呼びます。マスターには標準ラベルがあり、クラスター内のすべてのノードからマスターであるノードを正確に選択できます。

このXNUMXつのセクションで彼は間違いなくマスターに到達します。 そして彼はそこに住むことを許されるでしょう。

しかし、私たちはマスターのところに来るだけでは十分ではありません。 これでは何も得られません。 次に、次の XNUMX つのことを説明します。

hostNetwork: true 
hostPID: true 

起動するポッドがカーネル名前空間、ネットワーク名前空間、および PID 名前空間に存在することを指定します。 ポッドがマスター上で起動されると、このノードの実際のライブ インターフェイスをすべて表示し、すべてのトラフィックをリッスンし、すべてのプロセスの PID を確認できるようになります。

それからそれは小さなことの問題です。 etcd を使用して、必要なものを読み取ってください。

最も興味深いのは、デフォルトで存在するこの Kubernetes 機能です。

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

そしてその本質は、このクラスターに対する権限がなくても、起動するポッド内で、hostPath タイプのボリュームを作成したいと言えることです。 これは、起動するホストからパスを取得し、それをボリュームとして取得することを意味します。 そして、それを「ホスト」という名前にします。 この hostPath 全体をポッド内にマウントします。 この例では、/host ディレクトリに移動します。

もう一度繰り返します。 ポッドに、マスターに来て、そこで hostNetwork と hostPID を取得し、マスターのルート全体をこのポッド内にマウントするように指示しました。

Debian では bash が実行されており、この bash は root で実行されることがわかります。 つまり、Kubernetes クラスター内で権限を持たずに、マスター上で root を取得しただけです。

次に、全体のタスクは、サブディレクトリ /host /etc/kubernetes/pki に移動し、そこにあるクラスターのすべてのマスター証明書を取得し、それに応じてクラスター管理者になることです。

このように見ると、ユーザーがどのような権限を持っているかに関係なく、これらはポッドにおける最も危険な権限の一部です。

クラスターの一部の名前空間でポッドを実行する権限がある場合、このポッドにはデフォルトでこれらの権限が与えられます。 特権付きポッドを実行できます。これらは通常、ノード上のすべての権限であり、事実上 root です。

私のお気に入りはRootユーザーです。 そして、Kubernetes にはこの「非ルートとして実行」オプションがあります。 これはハッカーからの保護の一種です。 「モルダビアウイルス」ってご存知ですか？ もしあなたが突然ハッカーになって私の Kubernetes クラスターに来たとしたら、私たち下手な管理者は次のように尋ねます。 そうしないと、ポッド内のプロセスを root で実行することになり、簡単に私をハッキングしてしまうことになります。 自分の身は自分で守ってください。」

私の考えでは、ホスト パスのボリュームは、Kubernetes クラスターから望ましい結果を得る最も速い方法です。

しかし、これをどうすればいいのでしょうか？

Kubernetes に出会った普通の管理者は次のような考えを抱くはずです。「ああ、言ったでしょう、Kubernetes は機能しません。 穴が空いています。 そしてキューブ全体はでたらめだ。」 実際、ドキュメントというものがあり、そこを見ると、次のセクションがあります。 ポッドセキュリティポリシー.

これは yaml オブジェクトです。Kubernetes クラスター内に作成できます。これは、特にポッドの説明でセキュリティの側面を制御します。 つまり、実際には、起動時にポッド内にある任意の hostNetwork、hostPID、特定のボリューム タイプを使用する権限を制御します。 ポッド セキュリティ ポリシーを利用すると、これらすべてを説明できます。

ポッド セキュリティ ポリシーで最も興味深い点は、Kubernetes クラスターでは、すべての PSP インストーラーがまったく記述されていないだけでなく、単にデフォルトで無効になっているということです。 ポッド セキュリティ ポリシーは、アドミッション プラグインを使用して有効になります。

さて、ポッド セキュリティ ポリシーをクラスターにデプロイしましょう。名前空間に管理者のみがアクセスできるいくつかのサービス ポッドがあるとします。 それ以外の場合はすべて、ポッドの権限が制限されているとします。 ほとんどの場合、開発者はクラスター内で特権付きポッドを実行する必要がないからです。

そして、私たちにとってはすべてがうまくいっているようです。 そして、Kubernetes クラスターは XNUMX 分でハッキングされることはありません。

問題があります。 Kubernetes クラスターを使用している場合は、クラスターにモニタリングがインストールされている可能性があります。 私は、クラスターにモニタリング機能がある場合、そのクラスターは Prometheus と呼ばれるだろうとさえ予想します。

これからお話しすることは、Prometheus オペレーターと純粋な形式で提供される Prometheus の両方に当てはまります。 問題は、管理者をクラスターにすぐに参加させることができない場合は、さらに調査する必要があることを意味するということです。 あなたの監視の助けを借りて検索することができます。

おそらく全員が Habré に関する同じ記事を読んでおり、モニタリングはモニタリング名前空間に配置されています。 ヘルム チャートは、誰にとってもほぼ同じように呼ばれます。 Helm install stack/prometheus を実行すると、ほぼ同じ名前になると思います。 そしておそらく、クラスター内の DNS 名を推測する必要さえありません。 それは標準だからです。

次に、特定のポッドを実行できる特定の dev ns があります。 そして、このポッドから次のようなことを行うのは非常に簡単です。

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics は、Kubernetes API 自体からメトリクスを収集する Prometheus エクスポーターの XNUMX つです。 そこには、クラスター内で何が実行されているか、クラスターでどのような問題が発生しているかなど、大量のデータがあります。

簡単な例として:

kube_pod_container_info{namespace=”kube-system”,pod=”kube-apiserver-k8s-1″,container=”kube-apiserver”,image=

「gcr.io/google-containers/kube-apiserver:v1.14.5」

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

特権のないポッドから単純なcurlリクエストを行うことで、次の情報を取得できます。 実行している Kubernetes のバージョンがわからない場合でも、簡単に教えてもらえます。

そして最も興味深いのは、kube-state-metrics にアクセスするだけでなく、Prometheus 自体にも同様に簡単に直接アクセスできることです。 そこからメトリクスを収集できます。 そこからメトリクスを構築することもできます。 理論上でも、Prometheus のクラスターからそのようなクエリを構築することができ、単にクエリをオフにするだけです。 そして、クラスターからの監視は完全に停止します。

そしてここで、外部モニタリングがあなたのモニタリングを監視しているかどうかという疑問が生じます。 私自身に影響を与えることなく、Kubernetes クラスターで運用する機会を得ました。 もう監視がないので、私がそこで活動していることさえ気づかないでしょう。

PSP と同じように、Kubernetes や Prometheus などの派手なテクノロジがすべて機能せず、穴だらけであることが問題のように感じられます。 あまり。

そんなことあるんですね～ ネットワークポリシー.

あなたが普通の管理者であれば、ネットワーク ポリシーについては、これが単なる別の yaml であり、クラスター内にすでに多数存在することを知っているでしょう。 また、一部のネットワーク ポリシーは明らかに必要ありません。 また、ネットワーク ポリシーが何であるかを読んだとしても、それは Kubernetes の yaml ファイアウォールであり、名前空間間、ポッド間のアクセス権を制限できるため、Kubernetes の yaml 形式のファイアウォールは次の抽象化に基づいていると確信できます。 ...いいえ、いいえ。 これは絶対に必要ありません。

たとえセキュリティ専門家に、Kubernetes を使用すると非常に簡単でシンプルなファイアウォールを構築できること、そして非常に詳細なファイアウォールを構築できることを伝えていなかったとしてもです。 彼らがこれをまだ知らず、あなたに迷惑をかけない場合は、「まあ、ちょうだい、ちょうだい…」となりますが、いずれにせよ、クラスターから取得できるいくつかのサービス プレースへのアクセスをブロックするネットワーク ポリシーが必要です。何の許可もなしに。

上記の例のように、権限がなくても、Kubernetes クラスター内の任意の名前空間から kube 状態メトリクスを取得できます。 ネットワーク ポリシーにより、他のすべての名前空間から監視名前空間へのアクセスが遮断されています。それだけです。アクセスがなくても問題はありません。 標準の Prometheus とオペレーターにある Prometheus の両方に存在するすべてのチャートには、helm 値に単純にネットワーク ポリシーを有効にするオプションがあります。 電源をオンにするだけで機能します。

実はここで問題が XNUMX つあります。 普通のひげを生やした管理者であれば、ネットワーク ポリシーは必要ないと判断した可能性が高いでしょう。 そして、Habr などのリソースに関するあらゆる種類の記事を読んだ後、特にホスト ゲートウェイ モードを使用する場合は、フランネルが選択できる最良の選択であると判断しました。

何をしますか？

Kubernetes クラスターにあるネットワーク ソリューションを再デプロイしたり、より機能的なものに置き換えたりしてみてください。 たとえば、同じキャリコの場合。 しかし、すぐに言っておきたいのは、Kubernetes が動作しているクラスター内のネットワーク ソリューションを変更するタスクは、まったく簡単ではないということです。 私はこれを XNUMX 回解きました (ただし、どちらも理論上) が、Slurms でその解き方も示しました。 学生向けに、Kubernetes クラスター内のネットワーク ソリューションを変更する方法を示しました。 原則として、実稼働クラスターでダウンタイムが発生しないように努めることができます。 しかし、おそらく成功しないでしょう。

そして、この問題は実際には非常に簡単に解決されます。 クラスター内には証明書があり、証明書の有効期限が XNUMX 年以内に切れることがわかっています。 そうですね、通常はクラスター内に証明書を使用する通常のソリューションです。なぜ心配するのですか。近くに新しいクラスターを作成し、古いクラスターを腐らせて、すべてを再デプロイします。 確かに、腐ってしまったら一日放置しなければなりませんが、ここに新たな塊ができています。

新しいクラスターを育てるときは、同時にフランネルの代わりにキャリコを挿入します。

証明書の発行期限が XNUMX 年間あり、クラスターを再デプロイする予定がない場合はどうすればよいでしょうか? Kube-RBAC-Proxy というものがあります。 これは非常に優れた開発であり、Kubernetes クラスター内の任意のポッドにサイドカー コンテナーとしてそれ自体を埋め込むことができます。 そして実際には、Kubernetes 自体の RBAC を通じてこのポッドに認可を追加します。

問題が XNUMX つあります。 以前は、この Kube-RBAC-Proxy ソリューションは、オペレーターの Prometheus に組み込まれていました。 しかしその後、彼はいなくなってしまいました。 現在のバージョンでは、ネットワーク ポリシーがあり、それを使用してネットワーク ポリシーを閉じるという事実に依存しています。 したがって、チャートを少し書き直す必要があります。 実際に行ってみると、 このリポジトリ、これをサイドカーとして使用する方法の例があり、チャートを最小限に書き直す必要があります。

もう XNUMX つ小さな問題があります。 Prometheus は、そのメトリクスを誰にでも配布している唯一の企業ではありません。 すべての Kubernetes クラスター コンポーネントは、独自のメトリクスを返すこともできます。

しかし、すでに述べたように、クラスターにアクセスして情報を収集できない場合は、少なくとも何らかの損害を与える可能性があります。

そこで、Kubernetes クラスターが破壊される XNUMX つの方法を簡単に説明します。

これを言うと笑われるでしょうが、これらは実際の XNUMX つのケースです。

方法 XNUMX。 資源の枯渇。

別の特別なポッドを起動しましょう。 このようなセクションがあります。

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

ご存知のとおり、リクエストとは、リクエストのある特定のポッド用にホスト上で予約されている CPU とメモリの量です。 Kubernetes クラスター内に XNUMX コアのホストがあり、そこに XNUMX つの CPU ポッドがリクエストとともに到着すると、リクエストのあるポッドはそれ以上このホストに到着できなくなることを意味します。

このようなポッドを実行する場合は、次のコマンドを実行します。

$ kubectl scale special-pod --replicas=...

そうすれば、他の誰も Kubernetes クラスターにデプロイできなくなります。 すべてのノードでリクエストがなくなるためです。 したがって、Kubernetes クラスターを停止します。 これを夕方に行うと、かなり長い間デプロイメントを停止できます。

Kubernetes のドキュメントをもう一度見ると、制限範囲と呼ばれるものが見つかります。 クラスターオブジェクトのリソースを設定します。 yaml で Limit Range オブジェクトを記述し、それを特定の名前空間に適用すると、この名前空間でポッドのデフォルト、最大、最小のリソースがあると言えます。

このようなものの助けを借りて、ポッド上であらゆる種類の厄介なことを示すことができるチームの特定の製品名前空間のユーザーを制限できます。 しかし、残念ながら、複数の CPU に対するリクエストでポッドを起動できないとユーザーに伝えたとしても、素晴らしいスケール コマンドが存在するか、ダッシュボードからスケールを行うことができます。

ここから 11 番目の方法が生まれます。 111 個のポッドを起動します。 それは111億です。 これは私がそのような数字を思いついたわけではなく、自分で見たからです。

本当の話。 夕方遅く、私はオフィスを出ようとしていた。 開発者のグループが隅に座ってラップトップで必死に何かをしているのが見えます。 私は彼らに近づき、「どうしたの？」と尋ねます。

少し早い夜のXNUMX時頃、開発者の一人が帰宅の準備をしていました。 そして私は、「今度はアプリケーションを XNUMX つにスケールダウンしよう」と決心しました。 XNUMX つ押しましたが、インターネットの速度が少し遅くなりました。 彼はもう一度 XNUMX を押し、もう XNUMX を押して Enter をクリックしました。 私はできる限りすべてを突いた。 その後、インターネットが誕生し、すべてがこの数字にまで縮小され始めました。

確かに、この話は Kubernetes 上で行われたものではなく、当時は Nomad 上で行われていました。 Nomad がスケーリングしようとする執拗な試みを XNUMX 時間止めようとした後、Nomad はスケーリングをやめず、他には何もしないと答えたという事実で終わりました。 「疲れた、もう帰るよ。」 そして彼は丸くなった。

当然のことながら、Kubernetes でも​​同じことをしようとしました。 Kubernetes は 1 億個のポッドに満足していないと彼は言いました。 内部マウスガードを超えています。」 しかし、000 個のポッドならそれが可能です。

XNUMX億に応じて、キューブはそれ自体に撤退しませんでした。 彼は本当にスケーリングを始めました。 プロセスが進むほど、新しいポッドの作成に時間がかかりました。 しかし、それでもプロセスは続きました。 唯一の問題は、名前空間で無制限にポッドを起動できる場合、リクエストや制限がなくても、いくつかのタスクを含む非常に多くのポッドを起動できるため、これらのタスクの助けを借りてメモリ内、CPU 内でノードが増加し始めることです。 非常に多くのポッドを起動すると、それらからの情報はストレージ、つまり etcd に保存されるはずです。 そして、そこに到着する情報が多すぎると、ストレージの復帰が非常に遅くなり、Kubernetes が鈍くなり始めます。

そしてもう XNUMX つ問題があります...ご存知のとおり、Kubernetes の制御要素は XNUMX つの中心的なものではなく、複数のコンポーネントです。 特に、コントローラー マネージャー、スケジューラーなどがあります。 これらすべての人は同時に不必要で愚かな仕事をし始め、時間が経つにつれて、ますます時間がかかり始めます。 コントローラー マネージャーは新しいポッドを作成します。 スケジューラはそれらの新しいノードを見つけようとします。 おそらく、クラスタ内の新しいノードがすぐになくなるでしょう。 Kubernetes クラスターの動作はますます遅くなります。

しかし、私はさらに先に進むことにしました。 ご存知のとおり、Kubernetes にはサービスと呼ばれるものがあります。 そうですね、クラスターのデフォルトでは、ほとんどの場合、サービスは IP テーブルを使用して動作します。

たとえば、XNUMX 億のポッドを実行し、スクリプトを使用して Kubernetis に新しいサービスを強制的に作成するとします。

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

クラスターのすべてのノードで、さらに多くの新しい iptables ルールがほぼ同時に生成されます。 さらに、サービスごとに XNUMX 億の iptables ルールが生成されます。

私はこのすべてを数千、最大 XNUMX 件でチェックしました。 そして問題は、すでにこのしきい値に達しているため、ノードに ssh を実行するのは非常に問題があるということです。 なぜなら、パケットは非常に多くのチェーンを通過するため、あまり良くないと感じ始めるからです。

これも、Kubernetes の助けを借りてすべて解決されます。 このようなリソース クォータ オブジェクトがあります。 クラスター内のネームスペースで使用可能なリソースとオブジェクトの数を設定します。 Kubernetes クラスターの各名前空間に yaml オブジェクトを作成できます。 このオブジェクトを使用すると、この名前空間に特定の数のリクエストと制限が割り当てられていることがわかり、この名前空間では 10 個のサービスと 10 個のポッドを作成できることがわかります。 そして、一人の開発者が少なくとも夕方には自分の首を絞める可能性があります。 Kubernetes は彼に、「リソースがクォータを超えているため、ポッドをその量までスケールすることはできません」と通知します。 以上です、問題は解決しました。 ドキュメントはこちら.

この点に関して、一つの問題点が生じます。 Kubernetes で名前空間を作成することがいかに難しくなっているかを感じます。 それを作成するには、多くのことを考慮する必要があります。

リソース割り当て + 制限範囲 + RBAC
• ネームスペースを作成する
• 内部に制限範囲を作成する
• リソースクォータ内に作成
• CI のサービスアカウントを作成する
• CI とユーザーのロールバインディングを作成する
• 必要に応じて、必要なサービス ポッドを起動します。

したがって、この機会を利用して私の開発状況を共有したいと思います。 SDKオペレーターと呼ばれるものがあります。 これは、Kubernetes クラスターが演算子を作成する方法です。 Ansible を使用してステートメントを作成できます。

最初は Ansible で書かれていましたが、SDK オペレーターがあることに気づき、Ansible のロールをオペレーターに書き直しました。 このステートメントを使用すると、Kubernetes クラスター内にコマンドと呼ばれるオブジェクトを作成できます。 コマンド内で、このコマンドの環境を yaml で記述することができます。 また、チーム環境内では、非常に多くのリソースを割り当てていると説明できます。

ほんの少し この複雑なプロセス全体を簡単にする.

そして結論としては。 これをどうすればいいでしょうか？
初め。 ポッドセキュリティポリシーは良好です。 そして、今日に至るまでどの Kubernetes インストーラーもこれらを使用していないという事実にもかかわらず、クラスター内でそれらを使用する必要があります。

ネットワーク ポリシーは、単なる不要な機能ではありません。 これはクラスターで本当に必要なものです。

LimitRange/ResourceQuota - いよいよ使用します。 私たちはこれをずっと前に使い始めましたが、長い間、誰もがそれを使っていると確信していました。 これは珍しいことが判明しました。

レポート中に述べたことに加えて、クラスターを攻撃できる文書化されていない機能があります。 最近発売された Kubernetesの脆弱性の広範な分析.

とても悲しくて傷つくこともあります。 たとえば、特定の条件下では、Kubernetes クラスター内のキューブレットが warlocks ディレクトリの内容を権限のないユーザーに提供する可能性があります。

ここで 私があなたに話したすべてを再現する方法についての指示があります。 ResourceQuota と Pod Security Policy がどのようなものかを示す実稼働例を含むファイルがあります。 そして、これらすべてに触れることができます。

ありがとうございました。

出所： habr.com