こいついつもマルチテナントの話してるな、という感じですが、今回もDatadog マルチテナントのトピックになります。 組織間のサイロを統合プラットフォームで打破するというDatadog オブザーバビリティと言いながらも、やっぱりサイロには勝てなかったよ……と言いたくなる気持ちを抑えつつ、他組織にはデータを見せたくないといったマルチテナント的な要望は日本に限らずあります。大規模な組織ではなおさらですし、セキュリティ的にも重要なトピックです。

おさらい

前回の記事 をぜひ一度読んでいただければと思いますが、Datadog のマルチテナント的な設計をするときに使える機能はいくつかあります。

RBAC

もっとも基本的なロールベースのアクセスコントロールです。機能単位で使える使えないをユーザーに設定できる一方で、主にテナントの中の権限制御に使います。

組織分割

申請ベースで使えるようになる機能で、既存の組織の配下に子組織を作ることができます。組織間では利用量以外のデータは一切共有されません。 ある意味最強のマルチテナントです。

Cross Organization Visibility

組織分割とセットで使います。メトリクスやログなど、特定のテレメトリを親子または子同士、つまりアカウントに関連のある組織の間で共有できます。ただし、共有の方法はダッシュボードまたはノートブックになりますので、例えばログを子から親に共有したときに、親のLog Explorer でこのログを検索できるというわけではなく、ダッシュボードのウィジェットから部分的にログを参照するということに注意です。

Data Access Control (DAC)

前回の記事で残念な使いづらい微妙な伸びしろのある機能扱いをしていましたが、ようやく機能が潤沢にそろってきたので、今回はコチラがメイントピックとなります。

DAC は組織の中で、機能単位ではなく、定義したデータセット単位でアクセスを制御する機能です。組織を分割せずにマルチテナント設計をしようとするとDAC （かダッシュボード配布）を使うのですが、データセット以外のデータにはデフォルトでアクセスできるという仕様から、ちょっと設計をミスってしまうと普通にデータがテナント間で漏れるというリスクがありました。つまり、ファイアウォール的に言えばデフォルトAllow のルールでした。

DAC のRestricted データセット（Strict Mode）

7月末のリリースで、ついにDAC のデフォルトDeny ルールであるRestricted データセットがサポートされました。ついでに、Agent Observability (LLM クエリの可視化)、Cloud Cost、Error Tracking、Software Delivery などがDAC の対象として新たに追加されました。

Data Access ControlDefine a Restricted Dataset for access controlDatadogでインフラストラクチャーとアプリケーションのモニタリング

Restricted データセットの動作について簡単に説明します。 デフォルトDeny の名の通りで、例えばhost:k8s-worker-1 のタグが付いたログをデータセットとして定義します（ほんとはホスト単位にするユースケースはあまりないと思いますが私の環境の都合上仕方なく）。そしてデータセットのアクセス権をAdmin ロールのユーザーにします。そしてデータセットをUnrestricted またはRestricted に設定します。

Unrestricted（これまで）の場合

• Admin ユーザー: k8s-worker-1 のログは見えますし他のホストのログも見えます
• Admin 以外のユーザー: k8s-worker-1 のログは見えませんが、他のホストのログは見えます

Restricted の場合

• Admin ユーザー: k8s-worker-1 のログは見えますが他のホストのログも見えません
• Admin 以外のユーザー: すべてのホストのログが見えません

上記のスクショはRestricted データセットをAdmin ユーザーに割り当てた時の見え方で、Admin ですらもログが完全にk8s-worker-1 しか見えないことが分かります。

なお、Restricted データセットなのに、Unrestricted と入っていてちょっとややこしいのですが「Roles and Teams with unrestricted access to all Logs data」という例外ユーザーみたいなものを定義できます。

これは、制限はかけたけども、とはいえすべてのログにアクセスできる超法規的な権限を持つユーザーです。制限が厳しすぎるとそれはそれで運用が辛い場面が出てくるので、例外的に緊急アクセスや統合的な管理者ユーザーを持っておくイメージです。

で、DAC のちょっとわかりづらいポイントなのですが、Restriction Key という概念を抑えておくのが設計のコツです。先ほどの例で言えばhost がRestriction Key となります。要はアクセス制限の軸となるタグのキーです（env とかsource とか）。Restriction Key は1つのテレメトリに関して1種類しか定義できません。ログに対してhost:k8s-worker-1 というRestriction Key でデータセットを作り、さらにenv:prod でデータセットを作ることはできません。切り口の排他性の保証がされず、両者に属するデータが出てきてしまう可能性があるため……かと思っていましたが、env タグを意図せず2つメトリクスに付けてしまうパターンとかもあるので、まあ仕様と受け入れるのが楽です。というか切り口の次元が増えると設計がほんとに大変になります。

DAC を使ったマルチテナント設計

では組織分割をせず、1 組織の中でDAC でマルチテナント設計をする際に、どのように進めていけばよいでしょうか？基本的には、運用性よりもデータ漏洩のリスクの方が怖いので、Restricted データセットで実装することになると思います。

次に、テナントの単位となりうるロールまたはチームを作成します。直感的なのはロールよりもチームがテナントになることだと思います。直接〇〇テナント用ロール、みたいな感じで定義するよりも、〇〇テナントチームを作成し、そのチームにユーザーを含め、ユーザーがロールを持つ方が自然です（以前からの繰り返しですがチーム自体にロールは割り当てられないことに注意）。ユーザー数が少ないならロールをテナントにしても構いませんが、マルチテナントをするということはそれなりの規模だと思います。

そして、データセットを定義します。データセットに対しては作成したチームを紐づけます。1つのデータセットには複数のテレメトリ、つまりログといっしょにAPM なども含めることができるので、「テナントの単位となりうるチームがアクセス可能な領域」をRestriction Key = タグで制御します。

最後に、データセットの作成したテレメトリをRestricted データセットに変更し、例外ユーザーとしてAdmin ロールのユーザーを設定しておくと、何かあったときにDAC の設定を変えず（つまり事故のリスクを削減して）アクセスができます。

アーキテクチャのイメージとしてはこんな感じです。

なお、チームはInvite Only のものしかアクセスコントロールに使えない点は注意です（というか自分でチームコントロールできたらアクセスコントロールの意味もないので）。あと、現在の制限としてはカスタムではない、標準メトリクスがDAC の対象外となります。センシティブな情報を含むことはほとんどないかと思いますが、とはいえここまで来たら標準メトリクスも対応してほしいところです。

最後に

実は、Organization Groups なる、待望のアクセスコントロール機能が現在プレビューとなっております。

Organization GroupsCentrally manage roles, policies, and users across multiple Datadog organizations with Organization Groups.Datadogでインフラストラクチャーとアプリケーションのモニタリング

複数の組織をグルーピングし、一括で管理・ポリシー適用する機能です。これができると、組織分割のパターンで親組織からさらにガバナンスを効かせながら子組織を使わせることができるので、組織分割のマルチテナントが非常にやりやすくなるはずです。

よろしければプレビューに申し込んでみて、ぜひフィードバックを送ってみてはいかがでしょうか（他人事）。