CNDO 2021、Open Policy Agentを使ったポリシーアズコードの紹介

クラウドネイティブなシステムに関するオンラインカンファレンスCloud Native Days Spring 2021から、Open Policy Agent（OPA）を使った「ポリシーアズコード」のセッションを紹介する。

OPAを使ったポリシーアズコードを紹介するセッション

これは「Open Policy Agentで社内のコード統一する夢を見る」というタイトルでフューチャー株式会社のエンジニア、伊藤太斉氏が登壇したセッションとなる。

伊藤氏の自己紹介

フューチャー株式会社において伊藤氏は、顧客のインフラを支えるエンジニアリング以外に社外向けのブログなども執筆も行っており、社内へのオープンソース啓蒙活動にも力を入れているという。

今回のセッションではInfrastructure as code（IaC）を実現する中で各プロジェクトなどの違いによって生じる差異をポリシーとして定義し、その差異、違いをルールとして適用することで手組みによる作業を減らし、OPAによって自動化を実装した際の知見を紹介するものとなった。

OPAはオープンソースのポリシーエンジンとしてCI/CDに組み込むことで、インフラストラクチャーからアプリケーションまで広範な領域のセキュリティを確保するツールだが、今回のセッションではインフラストラクチャーをコード化して社内のエンジニアが活用する際にルールブックとして使う例となる。

フューチャー株式会社では、Terraformをインフラストラクチャーの構成管理に利用している。そして社内のプロジェクトごとにそれを再利用することで、ゼロからインフラストラクチャーを構成する手間を減らしていると解説した。

GCP上のインフラストラクチャーをTerraformで構成管理

しかし利用するエンジニア、プロジェクトによって差異が発生することは避けられず、TerraformにおいてもModuleを使うのかWorkspacesを使うのか、リポジトリーを単一にするのか複数利用するのかという「流派（違い）」が発生していたという。

Terraform，Ansibleそれぞれに流派が発生してしまうことを解説

結果として、GCP上で同じTerraformを使っていたとしても、構成の違いや規約の違いが生じてしまっていたという。これは多分にプロジェクトの属人化とも言えるし、プロジェクトそれぞれの違いとも言えるが、それ以上に全社共通のルールやプロジェクトごとのルールが明文化されていないことの影響も大きいだろう。

流派を防ぐには社内の標準化が必要と判断

それを踏まえて、Open Policy Agentをインフラストラクチャーの構成の違いをチェックするためのツール（Linter）として使うという事例を解説した。

Terraformの構成チェックにOPAを使う

最初に「Open Policy Agentとは何か」を解説している。オープンソースであること、CNCFのプロジェクトとしてすでにGraduationしたこと、そしてポリシーアズコードを実装するためにRegoという言語を用いて記述することなどが解説された。

OPAとは何か？

ここで強調していたのは、CNCF配下だからと言ってKubernetes専用ではなく、さまざまなインフラストラクチャーに利用できるという部分だ。

クラウドネイティブなシステムの代名詞となった感があるKubernetesに関して言えば、すでにKubernetes専用のポリシーエンジンKyvernoがCNCFのサンドボックスプロジェクトとして採用されている。OPAが汎用性を謳い、ルール記述言語としてRegoを利用しているのに比べて、Kyvernoはカスタムリソースによる実装、YAMLによるポリシー記述となり、OPAとKyvernoでは設計思想に大きな違いがあると言える。

OPAの動作概要を紹介

このスライドではJSONによる入力データを元に、Regoのルールをチェックした結果を同じくJSONで返すというOPAの仕組みを解説している。ちなみにこのスライドで利用されている図は、フューチャー株式会社のエンジニアによるブログ記事からの引用だ。

引用元：Policy as Code を実現する Open Policy Agent に憧れて。ポリシーコードでAPI仕様をLintする

フューチャー株式会社ではポリシーアズコードを実装するためのソフトウェアとして、HashiCorpが開発するSentinelとオープンソースのOPAの比較検討を行ったという。SentinelはHashiCloud専用で有償であることから、社内の利用にはオープンソースのOPAを選択したことが解説された。

SentinelとOPAを比較

ここでKyvernoが選択肢に挙げられなかったのは、使用するインフラストラクチャーがKubernetesに限定されているわけではなかったということもあるだろう。仮想マシンを含むインフラストラクチャーを想定すれば、OPAは妥当な選択肢と言える。

ここからは実際にデモを行って説明を行った。これはGCP上のインスタンスとしてWeb用のVMと電子メール用のVMを起動することを前提として、それぞれにweb_instanceとmail-instanceとしてTerraformの構成ファイルを記述する。これはHashiCorpが開発したHCL（HashiCorp Configuration Language）で書かれたコードだが、それを最終的にTerraformがJSONに変換し、そのJSONをOPAがRegoのツールに従って判定するというデモとなる。

利用するパブリッククラウドのインスタンスの名前の命名規則をOPAでチェックするというシンプルなデモだが、OPAの動作の基本は理解できる内容となっている。

デモでOPAの動作を解説

「OPAができること」というスライドでは、フューチャー株式会社におけるOPAの使い方の一例を紹介した。ここでは「利用するリソースに関するルール（制限）を実装する」という内容となっているが、OPAはそれ以外にも多様なポリシーを記述できると説明。一方、OPAが不得意とする領域もあるとして、その一例としてTerraformの構文チェックとしては使えないという点を指摘した。

OPAができないことを解説

最後にまとめとして、インフラストラクチャーを社内で横展開するためにはコード化（IaC）が必要であると語り、それをポリシーとして記述できるツールとしてSentinelとOPAを取り上げた。特にOPAはオープンソースとして利用が可能であること、Kubernetesに特化していないことなどから、応用範囲がひろいことなどを紹介した。

ただコード化されたコンテンツを維持管理していくためにはツールだけでは困難であり、ツールとその他の制約や文書を組み合わせた複合的な施策が必要であるとして発表を終えた。

OPAだけではなく他の要因も必要と訴求