Open Policy Agent で Kubernetes を保護する方法

コンテナ化されたアプリケーションを本番環境に移行する組織が増えるにつれて、Kubernetes はプライベート、パブリック、ハイブリッド クラウド環境でこれらのアプリケーションを管理する効果的な方法として登場しました。実際、Cloud Native Computing Foundation の調査によると、少なくとも 84% の組織がすでに業務でコンテナを使用しており、78% の組織が Kubernetes を使用してコンテナを展開しています。

[[342138]]

Kubernetes の強みと魅力は、ほとんどの最新 API とは異なり、Kubernetes API がインテントベースであることです。つまり、Kubernetes API を使用する組織は、Kubernetes でその目標を達成する方法を考えるのではなく、Kubernetes で何を実行したいかを考えるだけで済みます。これは拡張性と回復力に優れたシステムであり、そのため人気があります。つまり、Kubernetes はアプリケーションの配信を高速化します。

ただし、クラウド ネイティブ環境での変更は設計上不変であるため、その操作は非常に動的になります。動的性とスケールはリスク解決策として認識されており、今日の最新環境では、セキュリティ、運用、コンプライアンスに関する新たな課題が生じています。次の質問について考えてみましょう。ワークロードの権限レベルがマイクロ秒だけ存在する場合、どのように制御しますか?すべてのサービスが必要に応じて動的に構築される場合、どのサービスがグローバル インターネットにアクセスできるかをどのように制御しますか?ハイブリッド クラウド環境の境界はどこにありますか?クラウド ネイティブ アプリケーションは一時的かつ動的であるため、セキュリティ保護の要件ははるかに複雑になります。

Kubernetes の認証の課題

さらに、Kubernetes では認証に関して独自の課題があります。以前は、「承認」という単純な用語は、人々がどのようなアクションを実行できるか、または「誰が何をできるか」という概念を表していました。しかし、コンテナ化されたアプリケーションでは、この概念は拡張され、どのソフトウェアまたはどのマシンがどの操作を実行できるか (「何が何ができるか」とも呼ばれる) という概念も含まれるようになりました。一部のアナリストは、アカウント中心のルールを指すのに「ビジネス承認」という用語を使用し始め、それ以外のものには「インフラストラクチャ承認」という用語を使用し始めています。特定のアプリケーションに 15 人の開発者のチームがいるが、数千のサービスを持つ数十のクラスターとそれらの間の無数の接続で構成されている場合、「何ができるか」というルールがこれまで以上に重要になり、開発者が Kubernetes でそれらのルールを作成、管理、およびスケーリングするためのツールが必要であることは明らかです。

Kubernetes API は YAML ベースであるため、承認の決定を行うには、YAML の任意のブロックを解析する必要があります。これらの YAML ブロックは、各ワークロードの構成を定義する必要があります。たとえば、すべてのイメージが信頼できるリポジトリからのものであることを保証するポリシーを適用するには、YAML をスキャンしてすべてのコンテナのリストを見つけ、そのリストを反復処理して特定のイメージ名を抽出し、そのイメージ名の文字列を解析する必要があります。たとえば、別のポリシーとして「サービスが root として実行されないようにする」というポリシーがあります。この場合、YAML をスキャンしてコンテナのリストを検索し、このリストを反復処理してコンテナ固有のセキュリティ設定があるかどうかを確認し、それらの設定をグローバル セキュリティ パラメータと組み合わせる必要があります。残念ながら、従来の「ビジネス認証」アクセス制御ソリューション（ロールベースまたは属性ベースのアクセス制御、IAM ポリシーなど）は、ポッドのラベルを少し変更しただけでも、上記の基本ポリシーを適用できるほど強力ではありません。

急速に進化するコンテナの世界でも、変わらないことが 1 つあります。それは、セキュリティが後回しにされることが多いということです。現在、多くの組織の DevSecOps チームはセキュリティを開発サイクルに移行するために取り組んでいますが、適切なツールがなければ、課題やコンプライアンスの問題がずっと後になってから発見され、修正されることがよくあります。実際、DevOps プロセスの市場投入までの時間目標を真に達成するには、開発プロセスのかなり早い段階でセキュリティとコンプライアンスのポリシーを実装する必要があります。セキュリティ戦略は、開発の初期段階でリスクが排除された場合に最も効果を発揮することが証明されており、配信プロセスの最後にセキュリティの問題が発生する可能性が低くなります。

ただし、すべての開発者がセキュリティの専門家であるわけではなく、負担の大きい DevOps チームにとって、すべての YAML 構成を手動で確認することが、成功への唯一の確実な道となります。しかし、組織は効率性のためにセキュリティを犠牲にする必要はありません。開発者は、ガードレールを実装してミスやリスクを排除し、Kubernetes の展開が規制に準拠していることを保証することで開発をスピードアップするためのセキュリティ ツールを導入する必要があります。組織は、開発者、運用、セキュリティ チーム、そしてビジネス自体に有益な方法で全体的なプロセスを改善するアプローチを採用する必要があります。幸いなことに、最新のパイプライン自動化と「as code」モデルと組み合わせて使用​​することで、エラーと労力を削減できるソリューションがあります。

オープンポリシーエージェントの登場

Open Policy Agent (OPA) は、Kubernetes の「誰が何ができるか」と「何が何ができるか」を判断するためのツールとしてますます利用されるようになっています。 Open Policy Agent (OPA) は、Styra によって作成されたオープン ソース ポリシー エンジンであり、ビジネスおよびインフラストラクチャの承認のためのドメインに依存しない独立したルール エンジンを提供します。開発者は、Open Policy Agent (OPA) が Kubernetes に適していると感じています。これは、組織が任意の JSON/YAML に基づいてアクセス制御ポリシー (およびその他の多くのポリシー) を記述して適用する必要がある場合があるという前提で設計されているためです。 Open Policy Agent (OPA) は、セキュリティを強化してリスクを軽減しながら、Kubernetes 開発のスピードと自動化を向上させるポリシー適用ツールです。

実際、Kubernetes は Open Policy Agent (OPA) の最も人気のあるユースケースの 1 つです。組織が Kubernetes 用のカスタム コードの作成、サポート、保守を希望しない場合は、Open Policy Agent (OPA) を Kubernetes アドミッション コントローラーとして使用し、宣言型ポリシー言語である Rego を最大限に活用できます。たとえば、組織は、通常は Wiki や PDF、人々の頭の中に保存されているすべての Kubernetes アクセス制御ポリシーを取得し、コードとしてのポリシーに変換できます。これらのポリシーはクラスター上で直接適用できるため、Kubernetes 上でアプリケーションを実行する開発者は、作業中に内部 wiki や PDF ポリシーを常に参照する必要がありません。これにより、開発プロセスの早い段階でエラーが削減され、不適切なデプロイメントが排除され、生産性が向上します。

Open Policy Agent (OPA) が Kubernetes 固有の課題に対処するのに役立つもう 1 つの方法は、コンテキスト認識ポリシーを使用することです。これらのポリシーは、存在する他のすべての Kubernetes リソースに関する情報に基づいて、Kubernetes がリソースに関してどのような決定を下すかを決定します。たとえば、組織では、同じエントリ ポイントを使用して別のアプリケーションのグローバル インターネット トラフィックを盗むアプリケーションを誤って作成しないようにしたい場合があります。この場合、組織は「ホスト名が競合するイングレスを許可しない」というポリシーを作成し、新しいイングレスを既存のイングレスと比較することを義務付けることができます。さらに重要なのは、Open Policy Agent (OPA) により、Kubernetes の構成とデプロイメントが内部ポリシーと外部の規制要件に準拠していることが保証され、開発者、運用、セキュリティ チームにとってメリットがあることです。

ハイブリッドクラウド全体でKubernetesを保護する

通常、「Kubernetes」と言う場合、実際には Kubernetes コンテナ管理システム上で実行されるアプリケーションを指します。これは OPA を使用する一般的な方法でもあります。アプリケーション内からマイクロサービスまたはエンドユーザーのアクションを承認するかどうかを OPA に決定させます。 Kubernetes 環境に関しては、Open Policy Agent (OPA) は、宣言型ポリシーを任意の数のアプリケーションおよびインフラストラクチャ コンポーネントにテスト、パイロット、チューニング、統合するための完全なツールキットを提供します。

実際、開発者は、特にハイブリッド クラウド環境において、すべての Kubernetes クラスターにわたってポリシーを適用し、セキュリティを強化するために、Open Policy Agent (OPA) の使用を拡大することがよくあります。このため、多くのユーザーは Styra DAS も活用しています。Styra DAS は、Open Policy Agent (OPA) セキュリティ ポリシーを実行する前に検証してその影響を確認し、任意の数の Kubernetes クラスターに配布し、ポリシーを継続的に監視して意図した効果が得られるようにするのに役立ちます。

組織がクラウドとコンテナの取り組みのどの段階にいても、Kubernetes は現在、本番環境でコンテナを展開するための標準となっています。 Kubernetes 環境には、クラウド コンピューティング環境のセキュリティとコンプライアンスを確保するために組織が対処しなければならない新しい独自の課題がありますが、基礎的な思考の必要性を制限するソリューションも存在します。これらの課題に大規模に対処するために、Open Policy Agent (OPA) がデファクト スタンダードとして登場し、自動化されたポリシー適用を通じて組織のリスクを軽減し、アプリケーションの配信を加速できるようになりました。