オープンポリシーエージェント: クラウドネイティブのためのユニバーサルポリシーエンジン

Open Policy Agent (OPA) は、企業が分散アプリケーション、Kubernetes、マイクロサービスなどの承認ポリシーの作成と適用を簡素化するのに役立ちます。

クラウド コンピューティング テクノロジーを採用する組織が増えるにつれて、クラウド ネイティブ スタックのダイナミズムとスケールによって、より複雑なセキュリティとコンプライアンスが必要になることが分かってくるでしょう。たとえば、Kubernetes などのコンテナ オーケストレーション プラットフォームが普及するにつれて、開発チームと開発者は、コンピューティング、ストレージ、ネットワークなどの従来の領域だけでなく、アドミッション コントロールなどのポリシー領域に対しても新たな責任を負うようになります。同時に、各アプリケーション、マイクロサービス、またはサービス メッシュには独自の承認ポリシー セットが必要であり、開発者が責任を負います。

[[337018]]

これらの理由から、多くの組織は、クラウドでポリシーを作成、実装、管理するための、より簡単で時間のかからない方法を求めています。 4 年前にオープン ソースのドメインに依存しないポリシー エンジンとして作成された Open Policy Agent (OPA) は、クラウド ネイティブ ポリシーの事実上の標準になりつつあります。実際、Netflix、Pinterest、Goldman Sachs などの企業では、Kubernetes のアドミッション コントロールやマイクロサービス API 認証などのユース ケース向けに、すでに OPA を本番環境に導入しています。 OPA は、Atlassian スイートや Chef Automate など、すでによく知られ、愛用されているクラウド ネイティブ ツールの多くもサポートしています。

OPA は、クラウド ネイティブ組織に統一されたポリシー言語を提供するため、カスタム ポリシーをそれぞれの異なる言語やツールにハードコードすることなく、アプリケーション、API、インフラストラクチャなど全体で認可の決定を共通の方法で表現できます。さらに、OPA は認可専用に構築されているため、パフォーマンス最適化のコレクションが拡大しており、ポリシー作成者はほとんどの時間を正確で保守可能なポリシーの作成に費やし、パフォーマンスは OPA に任せることができます。

OPA 認可ポリシーには、コンテナ オーケストレーションのガードレールの設定から、SSH アクセスの制御、サービス メッシュのシナリオベースの認可の提供まで、スタック全体にわたる多くのユースケースがあります。多くの OPA ユーザーにとって優れた出発点となる、アプリケーション認証、Kubernetes アドミッション コントロール、マイクロサービスという 3 つの一般的なユース ケースがあります。

OPA認可を申請する

承認ポリシーは、ほぼすべてのアプリケーションで必要とされるため、広く普及しています。しかし、開発者は独自のコードを作成することが多く、時間がかかるだけでなく、ツールやポリシーが寄せ集めになり、メンテナンスが困難になります。承認はすべてのアプリケーションにとって重要ですが、ポリシーの作成に時間がかかると、ユーザー向けの機能に集中できる時間が減ります。

OPA は専用の宣言型ポリシー言語を使用して、承認ポリシーの開発を簡素化します。たとえば、組織は「この人が請負業者の場合、PII を読み取ることはできません」や「ジェーンはこのアカウントにアクセスできます」などのポリシーを直接作成して適用できます。しかし、これはほんの始まりに過ぎません。 OPA はコンテキストを認識するため、取引日の最後の 1 時間に要求された株式取引など、特定の名前空間内の特定のサービスでのみ実行できる数百万ドル規模の取引など、あらゆることを考慮したポリシーを作成することもできます。

もちろん、多くの組織ではすでにカスタムの義務が課されています。ただし、組織が開発者の効率性を維持しながらアプリケーションを分解し、クラウド内でマイクロサービスを拡張したい場合は、分散認証システムが必要です。

Kubernetes アドミッション コントロールのための OPA

多くのユーザーは、Kubernetes のガードレールを作成するために OPA も使用しています。 Kubernetes 自体が主流となり、ミッションクリティカルになるにつれて、組織はセキュリティとコンプライアンスのリスクを軽減するためにセキュリティガードレールを定義および実装する方法を模索しています。管理者は OPA を使用して明確なポリシーを確立できるため、開発者は運用、セキュリティ、コンプライアンスのリスクを心配することなく、パイプラインを本番環境に加速し、新しいサービスを迅速に市場に投入できます。

OPA を使用すると、同じホスト名を使用したイングレスを拒否するポリシーを作成したり、すべてのコンテナ イメージが信頼できるレジストリからのものであることを要求したり、すべてのストレージが常に暗号化ビットでマークされていることを確認したり、インターネットに公開されるすべてのアプリケーションが承認されたドメイン名を使用していることを確認したりすることができます。

OPA は Kubernetes API サーバーと直接統合されるため、コンピューティング、ネットワーク、ストレージなど、ポリシーによって禁止されているリソースを拒否できます。開発者にとって特に役立つのは、組織が継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインなどの開発サイクルの早い段階でこれらのポリシーを公開できるため、開発者は早期にフィードバックを得て、実行中に問題を修正できることです。さらに、組織はポリシーを帯域外で検証して、意図した効果が得られていること、不注意で問題を引き起こしていないことを確認することもできます。

マイクロサービス向け OPA

最後に、OPA は、組織がマイクロサービスとサービス メッシュ アーキテクチャを制御するのを支援する点で非常に人気が高まっています。 OPA を使用すると、組織はマイクロサービスに対して直接承認ポリシーを作成して適用したり (多くの場合、セカンダリ ツールとして)、サービス メッシュ内にサービス ポリシーを構築したり、セキュリティの観点からサービス メッシュ アーキテクチャ内の横方向の移動を制限するポリシーを作成したりできます。

クラウドネイティブアーキテクチャのための統一戦略の構築

一般的に、OPA を使用する全体的な目標は、クラウド ネイティブ スタック全体でポリシーを作成するための統一された方法を作成することです。これにより、組織は AD、部族の知識、Wikipedia、PDF、または多数の不一致なツールを通じてポリシーを継続的に管理する必要がなくなります。

これは、開発の簡素化と配信の高速化に加えて、セキュリティにとっても大きなニュースです。OPA により、たとえば不正アクセスが試みられた疑いがある場合に組織が確認する必要のあるツールの数が削減されるからです。同様に、運用とコンプライアンスの観点から見ると、OPA を使用すると、異機種環境間での情報の抽出と分析が容易になり、組織が問題を迅速に特定して迅速に解決できるようになります。

開発者は、クラウド ネイティブ環境向けのポリシー ベースのコントロールを作成および管理するための、よりシンプルで効率的な方法を求めています。多くの人にとって、その解決策は OPA です。組織が複数の場所、複数の言語、または複数のチームで承認ポリシーを扱う必要がある場合、OPA は冗長性を排除し、配信を高速化するのに役立ちます。