今日の分散システムにおけるポリシーの過負荷をナビゲートするためのガイド

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

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

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

これらの交流は、今日のクラウドネイティブおよび分散コンピューティングエコシステムで増大している問題を明らかにしています。「ポリシー」という用語は非常に広く使われているため、実質的に抽象的な表現です。

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

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

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

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

マイクロサービスと コンテナベースのアプリケーション がより一般的になるにつれて、サービスの通信方法を慎重に制御し、必要に応じて分離しておくことがさらに重要になっています。

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

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

アドミッションコントローラーは、Kubernetesの特殊なポリシーです。API リクエストを評価して、許可するか変更するかを決定します。彼らは本質的に門番です。API リクエストが進む前に、クラスター全体に特定の標準またはセキュリティ慣行を適用します。

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

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

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

• 安全でない構成の使用をブロックする

これらの種類のポリシーは、要求をインターセプトして変更することができます。そのため、クラスター内で一貫したセキュリティを維持するために非常に重要です。ただし、Kubernetes API 呼び出しライフサイクルのポリシーにのみ対応します。  

3. OPAとKyvernoの政策

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

Open Policy Agent(OPA)とKyvernoは、従来のアドミッションコントローラー以上のものを提供します。Kubernetes ではアドミッション コントローラーとして機能することがよくありますが、より柔軟で包括的なポリシー言語が導入されています。これにより、組織は複数のシステムにわたって複雑なルールを定義して適用できます。

• OPA(Open Policy Agent) は、環境をまたいで使用できる汎用性の高いポリシーエンジンです。複雑なポリシー要件を処理できる Rego と呼ばれる言語を使用します。Kubernetes に加えて、OPA は CI/CD パイプライン、マイクロサービス、さらにはクラウド リソースのポリシーを管理できます。

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

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

• ライフサイクル管理

• 検証

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

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

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

• クォータは通常、名前空間ごとに設定されます。名前空間が使用できるリソースの総量を制限するため、1 つの名前空間が引き継ぎすぎないようにします。

• 制限は、 コンテナまたはポッドが使用できるリソースの最小数と最大数を定義します。これにより、1 つのワークロードがリソースを使用しすぎて、システムの残りの部分に問題が発生することがなくなります。

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

これらのポリシーは、管理者がリソースのバランスをとるのに役立ち、動的にスケーリングする多数のユーザーまたはアプリを持つシステムでは特に重要です。ただし、これらのポリシーの管理は困難な場合があります。多くの場合、自動化や入室管理などの他のポリシーと重複します。

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

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

しかし、PSP は Kubernetes で段階的に廃止されつつあります。これらは、Pod Security Standards(PSS)などの新しいオプションや、OPAやKyvernoなどの外部ツールに取って代わられています。

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

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

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

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

• トラフィックの管理: サービス メッシュ ポリシーは、ルーティング、ロード バランシング、およびフェイルオーバーを制御します。これにより、A/B テスト、カナリア リリース、またはトラフィックを異なるサービス バージョンにルーティングすることなどが容易になります。  

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

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

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

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

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

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

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

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

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

まだフォローしていますか?「政策」の重なりは続いている...

まだ圧倒されていない場合は、ここにひねりがあります。現在、多くの組織がポリシーのポリシーを持っています。  

これらは「メタポリシー」と呼ばれます。これらはガードレールとして機能し、他のポリシーを作成、管理、または適用できるユーザーに関するルールを設定します。  

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

大規模なシステムでは、ポリシーの RBAC ポリシー が不可欠です。特定の管理者またはチームのみがポリシーを変更できるようにします。厳格な RBAC 制御を適用することで、これらの「ポリシーのポリシー」は、他のポリシーが重要なインフラストラクチャに行き過ぎたり干渉したりしないようにします。

最終的な考え: 政策の過負荷を乗り越えるロードマップ

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

ポリシーの過負荷を回避するには、明確な命名規則を使用し、各ポリシーの種類を定義するドキュメントを作成し、ポリシーツールを適切に活用することが重要です。

そして、次に技術カンファレンスで「ポリシー」と聞いたら、少し時間を取って「どちらですか?!"それはあなたを多くの混乱から救うかもしれません - さらにはホールを横断するスプリントさえも!

Illumioがクラウド、エンドポイント、データセンター環境全体でネットワークセキュリティポリシーをどのように簡素化できるかについては、今すぐお問い合わせください。