DevSecOps

Open Policy Agent (OPA)とは？

2023年までに、多くのアプリがクラウド専用に構築される見込みです。オンプレミスの静的な環境から柔軟なクラウド環境へ移行するにつれて、アクセス制御の重要性と複雑さが高まります。プラットフォームに安全策を導入するために、OPAが便利だと感じる企業は少なくありません。気になりますか？OPAの意味とトピックをさらに深掘りしましょう。

Open Policy Agent (OPA)の概要

オープンソースエンジンであるOpen Policy Agent Kubernetesは、宣言型のポリシーを記述し、それを意思決定に適用しやすくします。組み込み言語Regoを使って、多様なサービスに共通のルールを設定できます。

OPAには他にも次のような用途があります:

REST APIエンドポイントのアクセス権限を検証する。
コンプライアンスや安全に関する規定に基づき、Terraformの変更の可否を判定する。
ソフトウェアにカスタマイズしたアクセス制御ルールを適用する。
Kubernetes Admission Controllerを利用して、APIセキュリティリクエストを検証する。

‍

OPAで解決できる課題

OPAを使うと、リソースがどのように動作すべきかを定義したポリシー・アズ・コードを作成し、広範な環境へ自動的に展開できます。ポリシー・アズ・コードは、各リソースを手動で設定・監査する必要をなくす方法です。

コードベースのポリシーを使ってITインフラを構成すること自体は新しい概念ではありません。これはTerraform、Ansible、AWS CloudFormationといったインフラ・アズ・コードツールが長らく行ってきたことです。同様の方法がクラウド上のID・アクセス管理やデータセキュリティポリシーの運用にも活用されています。

ほかのポリシー・アズ・コードツールが特定のITリソースしか構成できない場合でも、OPAはクラウドインフラやクラウドのアクセス制御ルールなど、ほぼあらゆるITリソースを対象にできます。Kubernetesを使用していてAPIコールの管理を集中化したい場合や、クラウド上のリソースプロビジョニングを管理したい、あるいはファイアウォールを設定したいときなど、OPAは最適です。

‍

OPAの仕組みを再確認

OPAを導入すると、各アプリが個別にポリシーを管理するのではなく、集中管理されたポリシーマネージャーがサービスレベルのポリシーを制御します。OPAの基本理念は、ポリシーの意思決定と実行を常に切り離しておくことです。

OPAポリシーに対応するための要件

提供するサービスの性質に応じて、次のように固有のOPAポリシーガイドラインを作成できます:

ユーザーレベルでの認可やアクセス
インフラの設定
検証と監査
アプリレベルの認可に関するソリューション
国別ポリシーの運用

ポリシー管理については、OPSの集中管理サービスがあり、JSON over HTTPを介するRESTful APIを通じてアクセス可能です。OPAはアプリケーションサービスと連携しながら動作します。サービスがポリシーに関連する判定を必要とするときは、該当するOPA APIにリクエストを送信し、レスポンスを待ってポリシーの指示に従います。

技術的には、OPAをデーモンやコンテナ、あるいはライブラリとしてOS上で実行できます。OPA Kubernetesの大きな特徴は、ポリシーやサービスのデータを対象ホストのメモリに保持する点です。同じホスト上でサービスが動くため、ポリシーリクエストは即時に処理されます。

Open Policy Agent Example

ラベルは重要なので、不正なユーザーによるラベルの改変を防ぐ対策が必須です。また、人為的ミスを避けるために手動入力を減らすことが望ましいです。誤ったラベルが安全面にも影響し、運用上のトラブルにもつながる可能性があります。

具体例があるとOPAの実践がわかりやすくなります。以下の例では、OPAを使ってKubernetesのセキュリティを強化する方法を示しています。

package kubernetes.validating.existence
 
deny[msg] {
	not input.request.object.metadata.labels.department
	msg := "Every resource must have a department label"
}
 
deny[msg] {
	value := input.request.object.metadata.labels.department
	not startswith(value, "cccode-")
	msg := sprintf("Department code must start with `dcode-`; found `%v`", [value])
}

Regoとは何か

OPAのルールはすべてRego（「レイゴ」と発音）という宣言型の言語で記述します。関係データベースのルール表現に特化した設計となっています。Regoの詳細はドキュメントをご参照ください。

Regoは、長年使われてきた代表的なクエリ言語であるdatalogをベースに、JSONのような構造化ドキュメントを扱える機能を拡張したものです。

Regoのクエリを使うと、OPAが保持するデータに対してさまざまな条件を記述できます。これにより、システムの期待される状態に反するデータを列挙する形でポリシーを定義できます。

‍

OPAを管理・制御する方法

レイテンシを抑えるため、OPAの開発者はポリシーデータをすべてメモリに保存する設計にしました。これにより他のサービスからデータを取得する必要がありません。OPAと連携するには、目的別のAPIを利用できます:

Bundle service API: ポリシーデータをOPAに送るためのAPIです。OPAは常にBundle service APIをチェックし、新しいポリシーバージョンがあればダウンロードして適用します。
Status service API: OPAのサービス状況を確認するためのAPIです。現在アクティブなポリシーバージョンなどを表示します。
Decision log service API: OPAが行ったポリシー判断をすべてログに記録し、後にまとめてログサービス APIへ送信します。監査やトラブルシューティングに役立ちます。
ポリシー作成・テスト・デバッグ用ツール: opa testやrun、checksなどのコマンドラインツールが用意されています。開発を支援するVS Codeプラグインも利用できます。

‍

OPAとクラウドネイティブ環境

クラウドネイティブ環境には多くの構成要素があり、それらをセットアップ・削除・更新・監視・守る必要があります。OPAはポリシーを適用できるため、大規模環境の管理に役立ちます。

OPAは、以下のような重要なクラウドネイティブの取り組みで貴社をサポートします:

アプリの認可 - OPAでは宣言型のポリシー言語を使い、ルールを定義し実行できます。この機能により、アプリにポリシーを組み込むためのツール一式が提供されます。エンドユーザーがポリシーを編集できるように権限を与えることも可能です。
Kubernetesアドミッションコントロール — Kubernetesにはアドミッションコントロールポリシーを適用する機能があります。OPAを動的アドミッションコントローラーとして使うと、この機能を拡張できます。具体的にはリソースに注釈を付けたり、Podにサイドカーコンテナを挿入したりできます。
サービスメッシュの認可—サービスメッシュの管理や制御を行う際にもOPAは役立ちます。追加設定なしでサービスメッシュに認可ポリシーを組み込めるため、マイクロサービス間の水平通信を制限し、コンプライアンスを維持するのに有効です。

Use of the OPA in the Kuburnets

KubernetesのIngressを使うと、特定のサービスを公開または制限できますが、次のような問題が起きる可能性があります。

管理者がIngress設定を誤り、サービスをインターネットへ公開してしまう
過度なIngress権限により、Kubernetesが多数のロードバランサーを起動してクラウドコストが増大する
誤ったIngress構成により、既存のワークロードと同じホスト名を新しいワークロードが誤って使用し、サービス障害や機密情報の漏洩が発生する恐れがある
新しいホストが既存のIngressホストを使用するのを防ぐ例が示されたOPAポリシーがあります。

Kubernetes Ingressを守るためのOPA活用

以下のOPAポリシーは、新しいホストが既存のIngressホストと競合しないようにするものです。

package kubernetes.validating.ingress
 
deny[msg] {
	is_ingress
	input_host := input.request.object.spec.rules[_].host
    some other_ns, other_name
    other_host :=
    data.kubernetes.ingresses[other_ns][other_name].spec.rules[_].host
	[input_ns, input_name] != [other_ns, other_name]
 
	input_host == other_host
 
	msg := sprintf("Ingress host conflicts with ingress %v/%v", [other_ns, other_name])
}
 
input_ns = input.request.object.metadata.namespace
 
input_name = input.request.object.metadata.name
 
is_ingress {
	input.request.kind.kind == "Ingress"
	input.request.kind.group == "extensions"
	input.request.kind.version == "v1beta1"
}