OPA を使用してマルチクラウド ポリシーとプロセスの移植性を実現する方法

OpenPolicy Agent を使用すると、開発チームはマルチクラウドおよびハイブリッド クラウド環境全体で一貫したポリシーと承認を記述および適用できるようになります。

[[435919]]

マルチクラウド戦略が完全に主流になるにつれて、企業と開発チームは、クラウド環境全体で一貫したアプローチを作成する方法を考え出す必要があります。マルチクラウド自体は広く普及しています。クラウドを利用する企業のうち、実に 93% がマルチクラウド戦略を採用しており、Amazon Web Services、Google Cloud Platform、Microsoft Azure などの複数のパブリック クラウド ベンダーを使用しています。さらに、これらの企業の 87% は、パブリック クラウドとオンプレミスのクラウド環境を組み合わせたハイブリッド クラウド戦略を採用しています。

企業がクラウドに移行する主な理由は、コンピューティング、ストレージ、ネットワーク、データベース機能のパフォーマンス、可用性、スケーラビリティ、コスト効率を向上させることです。組織はベンダーロックインを回避するために、主にマルチクラウド戦略を採用します。

しかし、マルチクラウドは、元のクラウドネイティブ ロジックの拡張である、2 つ目の魅力的な可能性も提供します。つまり、クラウド コンピューティング アーキテクチャを抽象化して、クラウド プロバイダー間で自動的かつシームレスに (迅速ではないにしても) 移植し、パフォーマンス、可用性、コスト削減を最大化できるようにするか、少なくとも 1 つのクラウド ベンダーに障害が発生した場合に稼働時間を維持できるようにする機能です。 Kubernetes のようなクラウドに依存しないプラットフォームは、AWS、GCP、Azure、プライベート クラウドなど、どの環境でも同じように実行され、企業がこのマルチクラウドの移植性を実現する方法を垣間見ることができます。

理論的には優れていますが、マルチクラウドの移植性は実際には複雑です。ベンダー固有の機能、API、移植が困難なデータ レイクなどの依存関係により、真のアプリケーションとワークロードの移植性は複雑なプロセスになります。実際には、マルチクラウドの移植性は、組織がクラウド環境全体で一貫性を実現した場合にのみ実際に機能し、適切に機能します。これを実現するには、企業は前述のベンダー、クラウド、API などの間で機能するポリシー抽象化のレベルを必要とし、これによりクラウド ネイティブ ビジネス全体でスキル、人材、プロセスを簡単に移植できるようになります。個々のアプリケーションはクラウド間でシームレスに移植できるとは限りませんが、組織全体のアプローチはそうである必要があります。

OPAを使用してクラウド間で一貫したポリシーとプロセスを作成する

Open Policy Agent (OPA) は、ドメインに依存しないという理由から、人気のあるツールです。 Styra によって開発され、Cloud Native Computing Foundation に寄贈された OPA は、開発チームがクラウド ネイティブ環境全体で一貫性のあるコンテキスト認識型のポリシーと承認を構築、拡張、適用できるようにするオープン ソース ポリシー エンジンです。 OPA を使用すると、チームは任意の数の環境、任意の数の適用ポイント (クラウド インフラストラクチャ、Kubernetes、マイクロサービス API、データベース、サービス メッシュ、アプリケーション承認など) でポリシーを記述して適用できるため、組織はマルチクラウドおよびハイブリッド クラウド環境全体でポリシーを適用するための移植可能なアプローチを実現できます。

さらに、ポリシー・アズ・コード ツールとして、OPA を使用すると、組織は企業の wiki や人々の頭の中にあるポリシーを取得し、それを機械で処理可能なポリシー ライブラリにコード化することができます。 Policy as Code を使用すると、組織は任意の数のクラウドにわたってポリシーの適用を自動化できるだけでなく、シフトレフトしてポリシーを上流に挿入し、クラウド間で作業する開発チームの近くで、セキュリティ、運用、コンプライアンスのリスクをより迅速に把握して防止することもできます。 OPA と Terraform および Kubernetes を組み合わせる

たとえば、現在多くの開発者が、Terraform や AWS CDK などのインフラストラクチャ アズ コード (IaC) ツールと組み合わせて OPA を使用しています。開発者は IaC ツールを使用して、ベンダーがホストするクラウド インフラストラクチャに宣言的な変更を加え、インフラストラクチャの構成方法の望ましい状態を記述し、必要な変更を Terraform に判断させます。次に、開発者はポリシー・アズ・コード・ツールである OPA を使用してポリシーを記述し、Terraform によって提案された変更を検証し、本番環境に適用する前に構成ミスやその他の問題がないかテストします。

同時に、OPA は日常的なインフラストラクチャ変更の承認を自動化し、手動によるピアレビューの必要性 (およびそれに伴う人為的エラーの可能性) を削減できます。これにより、開発者にとって重要なセーフティネットと健全性チェックが作成され、リスクなしでさまざまな構成を試すことができます。クラウド インフラストラクチャ自体はベンダー間で移植可能ではありませんが、このアプローチは設計によるものです。

同様に、開発者は OPA を使用して、クラウド全体、さらにはさまざまな Kubernetes ディストリビューション全体で Kubernetes を制御、保護、および操作します。 Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理の標準となっています。 Kubernetes が移植可能であるのと同様に、Kubernetes 上で実行される OPA ポリシーも移植可能です。

OPA には多くの Kubernetes ユースケースがあります。たとえば、一般的なユースケースとしては、コンテナが正しくデプロイされ、適切な構成と権限が与えられていることを確認するために、OPA を Kubernetes アドミッション コントローラーとして使用することが挙げられます。開発者は、OPA を使用して Kubernetes のイングレスおよびエグレス決定を制御することもできます。たとえば、競合するホスト名によるイングレスを禁止するポリシーを記述して、アプリケーションが互いのインターネット トラフィックを盗むことがないようにすることができます。おそらく、マルチクラウド環境にとって最も重要なのは、クラウド全体の各 Kubernetes ディストリビューションが企業全体の企業セキュリティ ポリシーに準拠していることを証明できることです。

標準的なクラウドネイティブのビルディングブロックの作成

企業がパブリック クラウド間でアプリケーションをシームレスに移植できるようにするには、まず各クラウド ネイティブ環境の開発者向けに標準的なビルディング ブロックを作成する必要があります。このように、開発者は OPA を使用してポリシーを作成するだけでなく、CI/CD パイプライン内のセキュリティ、コンプライアンス、運用標準を自動化します。これにより、開発をスピードアップし、手動エラーを削減しながら、あらゆるマルチクラウド展開で繰り返し可能なスケーラビリティを実現できます。

OPA によるポリシーのコード化により、企業はパブリック クラウド用の Terraform とポリシー用の OPA、コンテナ管理用の Kubernetes とポリシー用の OPA、任意の数のマイクロサービス API およびアプリケーション承認ツールとポリシー用の OPA などのツールを使用しながら、それらのツールを CI/CI パイプライン内または開発者のラップトップ上で同じ OPA ポリシーを使用して実行できるようになります。

つまり、組織は、マルチクラウドの移植性のためにアプリケーションのリバースエンジニアリングに時間を無駄にする必要がありません。代わりに、共通のスキルを使用して、クラウド ネイティブ スタック全体にわたって繰り返し可能なプロセスを構築することに集中できます。

Tim Hinrichs は、OpenPolicyAgent プロジェクトの共同創設者であり、Styra の CTO です。それ以前は、OpenStackCongress プロジェクトの共同設立者であり、VMware のソフトウェア エンジニアでした。過去 18 年間にわたり、Tim はクラウド コンピューティング、ソフトウェア定義ネットワーク、構成管理、ネットワーク セキュリティ、アクセス制御など、さまざまな分野向けの宣言型言語を開発してきました。彼は博士号を取得した。彼は博士号を取得した。 2008年にスタンフォード大学でコンピューターサイエンスの博士号を取得。