今日の分散システムにおけるポリシーオーバーロードへの対応ガイド

KubeConに参加して、「ポリシー」に関するセッションに参加することをお勧めします。そこに着いたら、「これは実際にはどのような政策に関するものなのか」と疑問に思っても驚かないでください。

最近ソルトレイクシティで開催されたKubeConでは、タイトルで「ポリシー」が目立つセッションの合間に全力疾走していました。しかし、それぞれの話者にとって、その言葉の意味はまったく異なっていました。

ラベルベースのネットワークポリシーに焦点を当てている私は、「このポリシーセッションはネットワークポリシー、アドミッションコントローラー、またはコンプライアンスに関するものですか？」と事前に講演者を集めなければならないことがよくありました。

これらのやり取りから、今日のクラウドネイティブおよび分散コンピューティングエコシステムにおける問題が深刻化していることが明らかになりました。「ポリシー」という用語は非常に広く使われているため、それ自体が実質的に抽象化されています。

この問題を解き明かすために、この大まかな用語でよく議論される8種類のポリシーと、それらが分散システムのインフラストラクチャ、セキュリティ、自動化を理解する上でなぜ重要なのかを詳しく見ていきます。

1。ネットワークポリシー

ネットワークポリシーは、特にKubernetesのような環境において、ネットワーク内のシステムが相互に通信する方法を制御および管理するために重要です。

最も ネットワークポリシー 許可リストアプローチを使用してください。つまり、ポリシーで特に許可されていない限り、接続はデフォルトでブロックされます。これらのポリシーでは、IP アドレスまたはラベルに基づくルールを使用して、どのリソースが通信できるかを決定できます。

マイクロサービスとして、 コンテナベースのアプリケーション 一般化が進むにつれて、サービスの通信方法を注意深く管理し、必要に応じてサービスを分離することがさらに重要になります。

たとえば、Kubernetes ネットワークポリシーは高度にカスタマイズ可能です。内部トラフィック (東西) と外部トラフィック (南北) のトラフィックルールを設定できます。この柔軟性により、システムを安全に保つための強力なツールになりますが、構築と管理がより複雑になります。

2。アドミッションコントローラーポリシー

アドミッションコントローラーは Kubernetes に特化したポリシーです。API リクエストを評価して、許可すべきか変更すべきかを判断します。彼らは本質的にゲートキーパーです。API リクエストを先に進める前に、クラスター全体に特定の標準やセキュリティプラクティスを適用します。

たとえば、アドミッションコントローラーポリシーでは次のことができます。

• リソース制限を自動的に適用

• デプロイメントへのラベルの追加

• 安全でない設定が使用されないようにブロック

この種のポリシーは、リクエストをインターセプトして変更する可能性があります。そのため、クラスター内で一貫したセキュリティを維持するうえで極めて重要です。ただし、対象となるのは Kubernetes API 呼び出しライフサイクルのポリシーだけです。

3。OPAとKyvernoのポリシー

OPAとKyvernoのポリシーは単なるアドミッションコントローラーなのか、それともそれ以上のものなのか？

オープンポリシーエージェント（OPA）とKyvernoは、従来のアドミッションコントローラー以上の機能を提供します。Kubernetes ではアドミッションコントローラーとして働くことが多いですが、より柔軟で包括的なポリシー言語を導入しています。これにより、組織は複雑なルールを複数のシステムに定義して適用することができます。

• OPA (オープンポリシーエージェント) は、さまざまな環境で使用できる汎用性の高いポリシーエンジンです。Regoという言語を使用しており、複雑なポリシー要件を処理できます。Kubernetes の他に、OPA は CI/CD パイプライン、マイクロサービス、さらにはクラウドリソースのポリシーを管理できます。

• キベルノ は Kubernetes 専用に作られたポリシーエンジンです。YAML でポリシーを定義する簡単な方法です。Kubernetes の設定には多くの人がこの方法を好んでいます。ネイティブの Kubernetes オブジェクトとうまく連携するため、ポリシーの構築と適用が容易になります。

これらのツールはシステムへのアクセスを制御できますが、さまざまなアプリやシステムではさらに多くのことができます。以下のことを管理できます。

• ライフサイクル管理

• 検証

• カスタムコンプライアンスチェック

4。リソースクォータと制限ポリシー

リソース管理ポリシーは、Kubernetes クラスターが使用できる CPU、メモリ、ストレージの量を制御するのに役立ちます。これらのポリシーは、1 人のアプリやユーザーが 1 人のリソースを使いすぎないようにするため、共有環境では重要です。

• クォータ 通常は名前空間ごとに設定されます。1 つの名前空間が使用できるリソースの総量を制限するので、1 つの名前空間が過度に多くを占めることはありません。

• 限界 コンテナまたはポッドが使用できるリソースの最小数と最大数を定義します。これにより、1 つのワークロードがあまりにも多くのリソースを消費してシステムの他の部分に問題を引き起こすことがなくなります。

これらのポリシーを使用すると、管理者はリソースのバランスを取ることができます。これは、動的にスケーリングするユーザーやアプリが多い環境では特に重要です。これらのポリシーはシステムの安定性を維持するのに役立ちますが、自動化やアドミッションコントロールなどの他のポリシーレイヤーと相互作用するため、事態はさらに複雑になります。

これらのポリシーは、管理者がリソースのバランスを取るのに役立ちます。これは、動的にスケーリングするユーザーやアプリが多いシステムでは特に重要です。ただし、これらのポリシーの管理は難しい場合があります。多くの場合、自動化やアドミッションコントロールなどの他のポリシーと重複しています。

5。ポッドセキュリティポリシー (PSP)

のポッドセキュリティポリシー (PSP) クベルネテス Pod レベルでセキュリティ設定を設定します。これには、コンテナーが root として実行されないようにしたり、特定の Linux 機能を必要としたりすることが含まれます。

しかし、KubernetesではPSPは段階的に廃止されつつあります。ポッドセキュリティ標準 (PSS) などの新しいオプションや OPA や Kyverno などの外部ツールに取って代わられつつあります。

PSPは、過度に許容的な構成でワークロードが実行されないように、きめ細かなセキュリティ設定を追加するように設計されています。PSP は便利ですが、他のポリシーと一緒に PSP を管理すると混乱を招くことがあります。新しいツールでは、セキュリティを強化するためのより柔軟な方法が提供されており、一般的には「セキュリティポリシー」という用語が使われています。

6。サービスメッシュポリシー

マイクロサービス環境では、 サービスメッシュ IstioやLinkerdのように、サービス間の通信を保護および監視するポリシーレイヤーがもう1つ追加されています。これらのポリシーには次のようなものが多くあります。

• トラフィックの認証と承認: サービスメッシュは、mTLS (相同 TLS) を使用してサービス間の通信を暗号化します。また、サービス同士が通信できるポリシーを設定して、アクセス制御をさらに強化することもできます。

• トラフィックの管理: サービスメッシュポリシーは、ルーティング、負荷分散、およびフェイルオーバーを制御します。これにより、A/B テスト、カナリアリリース、さまざまなサービスバージョンへのトラフィックのルーティングなどが簡単になります。

ネットワークポリシーとは異なり、サービスメッシュポリシーはアプリケーション層で機能し、サービスの相互作用に影響します。これらのポリシーは、サービス間トラフィックの管理に不可欠です。ただし、ネットワークポリシーと重複しているため混乱を招くことがあります。

7。コンプライアンスポリシー

コンプライアンスポリシー システムがGDPR、HIPAA、SOC 2などの法的または社内のコンプライアンス要件を満たしていることを確認するためのデータ管理、アクセス、および運用基準をカバーできます。これらのポリシーは、セキュリティ、ロギング、およびデータストレージに影響を及ぼし、システムの多くの部分で大きな役割を果たす可能性があります。

たとえば、コンプライアンスポリシーでは、データを特定の場所にのみ保存する (データ保存場所) ことや、監査ログを一定期間保存することを義務付ける場合があります。Kubernetes では OPA や Kyverno などのツールがよく使用され、システムをリアルタイムで継続的に監視および監査して基準を満たしていることを確認し、これらのポリシーを実施しています。

コンプライアンスポリシーは、医療や金融など、規制が厳しい業界では特に重要です。それらはシステムの多くの部分にわたって機能し、セキュリティポリシーと重複することが多いため、管理が複雑になることがあります。とはいえ、システムの安全性、整理、コンプライアンスを維持するためには不可欠です。

8。自動化とライフサイクルポリシー

自動化ポリシーは、インフラストラクチャリソースをいつ、どのように作成、更新、削除するかを制御します。これらのポリシーは、リソース構成がコードとして記述され、CI/CD パイプラインを通じて管理される Infrastructure as Code (IaC) の重要な部分です。

たとえば、自動化ポリシーは、リソースの自動スケーリング、未使用のリソースのクリーンアップ、デプロイのライフサイクルのステップの管理などのタスクを処理できます。また、CI/CD パイプラインと統合して、ビルドの起動、テストの実行、デプロイの管理を行うこともできます。これにより、ワークロードの変化にリアルタイムで適応できる自己管理環境が構築されます。

自動化ポリシーは、リソース管理を簡素化し、クラウドネイティブ環境におけるベストプラクティスを保証します。ただし、リソース管理やアドミッションコントロールなどの他のポリシーと密接に連携するため、複雑さが増す可能性があります。

まだフォローしていますか？「ポリシー」の重複は続いています...

まだ圧倒されていないなら、ここにひねりを加えましょう。現在、多くの組織がポリシーに関するポリシーを定めています。

これらは「メタポリシー」と呼ばれます。それらはガードレールの役割を果たし、誰が他のポリシーを作成、管理、適用できるかを決めるルールを設定します。

たとえば、メタポリシーによって、特定のネットワークポリシーを作成できるチームや、アドミッションコントロールポリシーを作成する権限を誰が持っているかが決まる場合があります。これらのポリシーは、多くの場合、ロールベースのアクセス制御 (RBAC) に依存しています。

大規模システムでは、 RBACポリシー なぜなら、政策は不可欠だからです。特定の管理者またはチームのみがポリシーを変更できるようにします。これらの「ポリシー・フォー・ポリシー」は、厳密な RBAC 管理を実施することで、他のポリシーが重要なインフラストラクチャに過度な影響を及ぼしたり、干渉したりしないようにします。

まとめ:政策の過負荷を乗り越えるためのロードマップ

クラウドネイティブ環境や分散環境が拡大するにつれて、「ポリシー」の考え方は変化し続けるでしょう。それらはより複雑で専門的になり、時には矛盾することさえあるでしょう。

ポリシーの過負荷を避けるためには、明確な命名規則を使用し、各ポリシーの種類を定義する文書を作成し、ポリシーツールをうまく利用することが重要です。

そして、次に技術カンファレンスで「ポリシー」と聞いたら、少し時間を取って「どれ？！」と聞いてみてください。そうすれば大混乱からあなたを救えるかもしれませんし、クロスホールスプリントさえも防げます！

今日私たちと連絡を取ってください Illumioがどのようにクラウド、エンドポイント、データセンター環境全体のネットワークセキュリティポリシーを簡素化できるかをご覧ください。