Congress最新動向：OpenStackでセキュリティやコンプライアンスを守る仕組みとは？

今回のOpenStack SummitレポートはCongressプロジェクト^※1をとりあげます。Congressというプロジェクトには馴染みがない方が多いと思いますので少し説明しましょう。

※1 https://wiki.openstack.org/wiki/Congress

Congressは比較的新しいプロジェクトです。KiloリリースよりBig Tentの元で正式にリリースされるようになり、今回のLibertyではバージョン2.0.0がリリースされました。Big Tentにはたくさんのプロジェクトがある中で、あえてCongressを取り上げるのはなぜ？ と思われるかもしれません。OpenStackがIaaSの基盤（いわゆるコアプロジェクト）から領域を広げていますが、多くのプロジェクトは既存の領域の中で押さえられていない部分であったり、領域の外郭にそった部分を対象としています。その中にあって、Congressは今までにない方面からのアプローチであり、新しいタイプの取り組みであると思います。OpenStackにはこういうプロジェクトもあるのだ、というのを知ってもらい、広い範囲の方々に関心を持ってもらえればと思います。

Congressが管理するPolicyとは?

企業内や業務で使うためのシステムでは、さまざまなPolicyがあります。Policyというのは、別の言い方をすればルール、決め事、のような意味です。例えばよくあるのはセキュリティや、コンプライアンスのためのPolicyです。「インターネットに接続している仮想マシンが80ポートで通信してはいけない」であるとか、「DOSアタックを検出したらネットワークを隔離する」とか、「脆弱性のあるソフトウェアがインストールされているVMはネットワークから遮断する」というようなものです。

このようなPolicyは、従来は個別モジュールに対する作りこみであったり、場合によっては人によるチェックにより運用されてきました。しかしクラウドシステムの規模が大きくなり、複数の多様なシステムがクラウド上で動くようになると、このPolicyの運用を自動化したくなります。Congressはそのために開発されているプロジェクトです。

重要なことは、Congressを使えば、Policyを記述言語（Datalog）を使って定義できることです。今までしたら、nova、neutron、keystoneなどの情報を突き合わせて判断をしなければならなかったことが、一つのDatalogに記述するだけで、あとはCongressが各モジュールの情報を取得して動いてくれるのです。つまり、運用者は、DatalogでPolicyを定義するだけで、クラウド全体のガバナンスを管理できるようになります。それがCongressがGovernance as a Serviceと言われるゆえんです。

Congressはクラウド環境があるべき状態になっているか情報を収集し、検査と修正を行いクラウド環境にガバナンスをもたせることを目的としています。組織には、会計、セキュリティや開発など様々な部門があり、Policyとひとくくりにしても思い描くものが異なりますが、CongressではすべてのPolicyを扱えるようになることを目標としています。

図1: Congressの役割（https://www.openstack.org/summit/tokyo-2015/videos/presentation/rsvp-required-congress-hands-on-lab）

さて、本記事では、Congressプロジェクトについて、Design SummitでMitakaリリースに向けて議論が行われた内容を中心に紹介したいと思います。

スケール性と可用性の向上

Congressはスケール性と可用性のさらなる向上を目的として、Mitakaリリースではプロセス構成の変更が予定されています。LibertyリリースでのCongressは図に記載の通り大きく3種類のスレッドで構成されています。CongressへのAPIを受け付けるAPIスレッド、Policyの管理とPolicy違反の修正を行うPolicy Engineスレッドと、Policy管理対象からデータを取得するDataSource Driverスレッドに分かれています。Congressは初回のリリースとなるKiloリリースからシングルプロセス、マルチスレッド構成で動作をしています。そのため、Policyを適用する対象となるDataSourceの増加に合わせたスケールと、Congressプロセス自体の可用性を別途確保する必要がありました。

図2: Congressのアーキテクチャ概要

CongressプロジェクトではCongressのマルチプロセス化に向けてLibertyのリリース前から議論を開始しており、すでにPoCによる動作の確認を始めています。マルチプロセス構成では図での青い四角ごとに独立したプロセスとします。今回のDesign Summitでは、PoCで確認されているいくつかの問題の共有とその解決方法について議論を行いました。各問題に対して具体的な解決方法も出始めていることから、Mitakaリリースでのマルチプロセス化が期待されます。

Delegation

Congressでは様々なポリシーを管理することを目的としていますが、ポリシー違反の有無の確認などを迅速に行えるようにするために、適切な外部サービスへポリシー管理のDelegation（委任）機能の実現を目指しています。

この営みの一環として、Tokyo SummitではMonascaプロジェクトとのコラボレーションについて、Monascaプロジェクトの開発者を交えて議論を行いました。一定期間ごとの仮想マシンなどの仮想資源の稼働量や、ハイパーバイザの稼働量などのメトリックスに関連するポリシーを、MonascaにDelegationできるのではないかといった議論が行われました。Monascaプロジェクトでは監視したメトリックスを時系列に整理してアラームを上げる機能があり、Congressで管理する抽象的なポリシーを、具体的なアラーム設定に変換することで、Delegationの実現が可能となるのではないかと、Monascaプロジェクトより提案がありました。具体的な実現方法については未だ議論の最中のため、今後はIRCやMLで議論が継続されます。次回のAustinサミットにおいて大きな議題の一つになることが予想されます。

Push型DataSource Driver

Congressではポリシーによる監視対象を、それぞれDataSourceとしてDriverを作成して管理を行います。LibertyリリースにおいてCongressはPollingで各DataSourceの情報を取得する設計になっています。

OPNFVのコントリビュータよりOPNFV Doctorプロジェクト^※2のInspectorとしてCongressを利用するユースケースが紹介されました。DoctorプロジェクトはNFVを構成するインフラのFault Manangementを目的としたプロジェクトです。InspectorはDoctorの構成要素の一つで、インフラの故障検知を契機に故障したハードウェアと仮想マシンのマッピングを行い、故障内容に合わせた処理を実施します。

※2 https://wiki.opnfv.org/doctor

Inspectorのユースケースでは、Zabbixなど他の監視システムで検知した故障をCongressが受け取り、故障した仮想マシンを再作成するPolicyを利用します。つまり、Congressが他のシステムから受け取った情報を元にPolicy違反の有無を計算する、Push型の動作に対する要望がCongressのユーザより上がりました。

具体的なユーザの要望が上がってきたため、MitakaリリースにおいてPush型のDataSourceを実装することの同意が行われました。MitakaではCongressのDataSourceとして既存のPolling型に加えて、Push型のDataSourceも実現されることが期待されます。

まとめ

Congressはまだ若いプロジェクトです。今後のリリースで追加されていく機能には要注目です。Policyはどのような場面でも必要になるため、Monascaプロジェクトとのコラボレーションなど、Congressと他のプロジェクトとの連携が多くなっていくことが期待されます。