クラウドエージェントにOIDC（シークレットではなく）で本番環境へのクエリを許可する

クラウドエージェントに本番環境へのアクセスをOIDC（シークレットではなく）で許可する

Formal社では、シークレットを嫌っています。創業以来、インフラストラクチャにおける長期的なシークレットの数をゼロにすることを目指してきました。

私たちの製品と、顧客が製品とやり取りする方法にも、その哲学を反映させたいと考えています。 accordingly、数ヶ月前にOIDCインテグレーションを構築しました。これは、任意の機械ワークロードが、自身のインフラストラクチャIDの強みに基づいてFormalに認証し、オプションで人間のIDを付与できる方法です。

製品やCI/CDワークロードを超えて、OIDCをサポートすることが、エージェントがインフラストラクチャ内でさらに多くのことを実行できるようにするために非常に役立つこともわかりました。CursorやDevinのようなクラウドコーディングエージェント自体はOIDC発行者です。これは、Formalを通じて本番データやクラウドインフラストラクチャへの監査可能でポリシー制御された読み取り専用アクセスを、それらに与えることができることを意味します。

OpenID Connect (OIDC)

簡単な復習ですが、OIDC認証フローは機械ワークロードに対して次のように機能します。目標は、ワークロードのIDプロバイダー（IdP）から短命のトークンを取得し、それを外部サービス（リライイングパーティ、RPと呼ばれる）での身元証明として使用することです。リライイングパーティは通常、IdPに関する知識で事前に設定されています。

1. ワークロードは、環境からOIDC JWTトークンを取得します。これは環境変数（例：GitHub、GitLab）として提供される場合もあれば、ワークロードがメタデータエンドポイント（例：AWS、GCP、Azure）へのAPI呼び出しによって取得する必要がある場合もあります。通常、トークンは異なるRP間でのトークン再利用を防ぐために、RPに対してスコープが設定されます（例：Audience audクレームを設定）。
2. ワークロードは、取得したOIDCトークンをベアラートークンとして使用して（つまり、Authorization: Bearer eyJ...）、RPにAPI呼び出しを行います。
3. RPは、設定からJWKSエンドポイント（通常はhttps://idp.com/.well-known/openid-configurationのようなもの）を参照し、IdPの公開鍵を取得してJWTを検証します。
4. RPは、JWTがIdPの秘密鍵で署名されていることを検証します。RPは、認証条件としてJWTに埋め込まれたクレームの一部もチェックします。これは重要です。なぜなら、IdPは通常マルチテナントだからです。これらのクレームは、受信したIDをRP上の機械IDにマッピングするためにも使用されます。
5. すべてのチェックがパスした場合、API呼び出しは続行されます。場合によっては、OIDC経由で認証されたAPI呼び出しに、追加の認可条件が適用されます。

［画像: ワークロード、そのIDプロバイダー、およびFormal間のOIDC認証フロー］

FormalにおけるOIDC

当社のOIDCインテグレーションは上記のフローに従いますが、いくつかの重要な追加詳細があります。

• 顧客は各インテグレーションに対してCEL条件を指定できます。この条件が評価されてtrueになった場合にのみ、トークン認証が許可されます。さらに、OIDCクレームフィールドはPermissionsへの入力としても表示されるため、顧客は特定のコントロールプレーンAPIリクエストに対して、より詳細な認可条件を定義できます。
• OIDC認証された呼び出し元が呼び出せるエンドポイントの1つはCreateFederationTokenです。これは、ソースOIDCクレームフィールドを埋め込んだ短命のConnectorアクセス・トークンを返します。これは、ワークロードが長期的な認証情報を保存する必要なしに、コネクタを認証情報注入プロキシとして使用できることを意味します。
• SPIFFEワークロードもネイティブで動作します。Formalは、他のOIDCトークンと同様に、SPIREからのJWT-SVIDを検証し、SPIFFE IDはポリシーとパーミッションで利用可能です。
• OIDCは、Formal EndpointおよびKubernetes Egress Agentの認証にも使用できます。

人間のアイデンティティの証明

すべてのOIDCインテグレーションは、単一の機械ユーザーにマッピングされます。これはほとんどの従来の機械ワークロードにとって良いデフォルトモデルですが、私たちが気にかけている多くのワークロードは、それ自身の名において動作するわけではありません。例えば、CIジョブは通常、コミットをプッシュした人間に関連付けることができ、クラウドエージェントはしばしばSlackから誰かが開始したために実行されます。そのため、各インテグレーションはオプションで、Formalが人間のアイデンティティに解決し、ログに表示され、ポリシーの入力となるトークンクレームを定義できます。

ここに関わる2つのアイデンティティは、異なる種類の信頼を伴います。Formalは機械アイデンティティを暗号学的に認証できますが、人間のアイデンティティは下流のワークロードによってのみ主張されます。私たちはその主張を受け入れます。なぜなら、顧客はそれを行っているシステムを信頼しており、Formalがそれを信頼するように明示的に設定しているからです。

私たちは創業以来この形状をサポートしてきましたが、それは非常に異なるユースケースのためでした。多くの顧客は、Formalを使用してビジネスインテリジェンス（BI）ツールとそのデータソース間のデータベーストラフィックを制御しています。Metabaseのようなツールはデータベースごとに1つの認証情報しか使用できませんが、顧客はMetabaseにログインしている人間のユーザーに基づいて、しばしば制御を差別化して適用します。私たちは元々、エンドユーザーアイデンティティの伝播を、Metabaseが人間のアイデンティティをデータベースクエリに主張し、Formalがそれに対してポリシーを評価できるようにするために構築しました。

このパターンは、クラウドコーディングエージェント、特にチーム全体で共有され、誰でもSlack、Linear、またはGitHubから起動できるマルチプレイヤーエージェントにほぼ完璧に適合することがわかりました。クラウドエージェントプラットフォームは、起動する可能性のあるすべての人間に対して個別の認証情報を作成することは現実的ではありません。しかし、そのエージェントセッションが何であるか、どのリポジトリで作業しているか、そして誰がそれを開始したかを示す署名付きトークンを発行することはできます。私たちの顧客は、ログインしているユーザーを報告するためにMetabaseを信頼するのと同じように、その声明を出すためにエージェントプラットフォームを既に信頼しています。その結果、顧客は同じFormalプリミティブを使用して、Metabaseでデータベース列をマスクしたり、所有者のチームによってクラウドエージェントのインフラストラクチャへのアクセスを制御したりできます。

OIDCインテグレーションのドッグフーディング

Formal社では、自社製品を徹底的にドッグフードしています。本番データベース、S3バケット、ログクラスターの前に配置されたコネクタがあり、Formal Endpointを使用して開発者のラップトップ上のコーディングエージェントの使用状況を監視および制御しています。当社の本番テナントのコントロールプレーンはTerraformで完全に管理されているため、OIDCインテグレーションの最初の内部ユースケースの1つは、Terraform CloudがFormalコントロールプレーンに認証する方法を、長期的なAPIキーではなくOIDCを使用するように切り替えることでした。

私たちはいくつかのクラウドコーディングエージェントプラットフォームのヘビーユーザーであり、ラップトップからの開発を徐々にクラウドサンドボックスに移行しています。これらのクラウドエージェントにインフラストラクチャへのアクセスを与えることをためらっていました。なぜなら、それは詳細なスコープ設定があまりない静的な認証情報を渡すことを意味するからです。

しかし、OIDCがソリューションを提示しました。コーディングエージェントに静的な認証情報を割り当てる必要がなくなり、クラウドエージェントの特定の詳細（誰がそれを起動したか、どのGitHubリポジトリで作業しているかなど）に基づいてポリシーを評価できるようになりました。

以下は、クラウドエージェントをより生産的にするために見出したユースケースの非網羅的なリストです。

製品分析

多くの場合、製品分析ワークフローは、本番データベースからのデータに依存します（分析データベースにレプリケートしています）。例えば、新しい製品オブジェクトの採用率を測定するには、その製品オブジェクトのデータベースエントリを持つ顧客を実際に確認する必要があります。

遠くない過去には、このプロセスは手動で行われていました。エンジニアはこれらのワークフローのためにSQLクエリを手動で作成する必要がありました。コーディングエージェントはSQLの作成と結果の消化の両方に優れていますが、以前は安全に制御されたアクセスを与える方法がありませんでした。その結果、クエリを手動で実行し、結果をCSVとしてエクスポートし、それをエージェントのコンテキストに貼り付ける必要がありました。

しかし、OIDCが導入されたことで、各クラウドエージェントセッションを独自のIDとして扱う方法ができました。Cursorの友人たちと協力して作成したフローに触発され、クラウドエージェントが人間の所有者から本番データベースへの短命アクセスをリクエストする承認を得られるように設定しました。このフローは、OIDCインテグレーションと、ワークフローやポリシーの一時停止を含む、既存のプラットフォームプリミティブをいくつか使用します。

特に、エージェントはSlack経由で人間に対して、なぜアクセスが必要なのか、そしてどのくらいの期間必要なのかを正確に伝えることができます。人間が承認すると、アクセスはクラウドエージェントセッションIDとリクエストされた特定のデータベースにスコープされます。

非同期ワークフローのデバッグ

当社のワークフローオーケストレーションプロバイダーはリモートMCPサーバーを提供していないため、以前は長期的な認証情報なしでクラウドエージェントにアクセスを与える方法がありませんでした。これにより、実際の実行履歴に基づいてワークフローパフォーマンスを最適化するためにコーディングエージェントを使用する能力が制限されていました。

ワークフローオーケストレーターをFormalリソースとして登録し、読み取り専用APIキーをネイティブユーザーとして保存できます。OIDCを使用すると、クラウドエージェントは上記のデータベースと同様に、短命のアクセスをリクエストし、承認を得ることができます。リクエストは常にFormalに記録され、クラウドエージェントとそれを起動したエンジニアの両方に帰属します。

クラウドネイティブ機能のテスト

Formalプラットフォームは、AWS、GCP、Azureの多くのネイティブ機能をサポートしています。例えば、コネクタはIAMを使用してデータベースやKubernetesクラスターに認証できます。さらに、コントロールプレーンは各クラウドプロバイダーと統合してリソースを自動検出したり、ログをストレージバケットに送信したりできます。

これらの機能を反復処理する際、クラウドエージェントはOIDCを使用して、Formal開発テナントとクラウドプロバイダー上の開発アカウントの両方にフェデレートできるようになりました。これにより、エージェントはコードの変更がライブで代表的なクラウド環境で意図したとおりに機能することを確認できます。これにより、壊れやすいモックに頼ることなく、ループを閉じることができます。

例えば、最近Cursorのクラウドエージェントが、FormalコントロールプレーンにOIDC（例：Azure Workload Identityを使用）で認証するように当社のKubernetesオペレーターを拡張する作業を行いました。開発プロセス中に、そのエージェントに開発Azureアカウントへのアクセスを許可し、そこで新しいAKSクラスターをデプロイして、PRブランチからKubernetesオペレーターを実行しました。エージェントは、Formal開発テナントに接続することで、クラスターにFormalPolicy CRDを作成すると、そのポリシーが開発テナントに同期されることを確認でき、コード変更が意図したとおりに機能したことを証明しました。

結論

クラウドエージェントは、それ自体でループを閉じることができるようになると、著しく有用性が高まります。製品使用データを収集し、障害を調査し、現実的な環境で作業を検証できるはずです。しかし、それは再利用可能な長期的な認証情報を渡す必要があってはなりません。

OIDCは、個々のエージェント実行をユニークなワークロードIDとしてモデル化するのに役立ちます。エージェントがFormal経由で外部サービスにリクエストを行うとき、アクセスはそれを起動したエンジニア、作業中のリポジトリ、およびリクエストを行っている特定のエージェントセッションに結び付けることができます。本番環境へのアクセスは読み取り専用で承認ゲート付きのままですが、開発環境での権限は永続的になることなく広範囲に設定できます。

当社の内部使用から得られるより広範な教訓は、エージェントアクセスは、別の長期的なシークレットを持つ別の機械ワークロードとしてではなく、一時的な委任としてモデル化されるべきだということです。その区別が存在すれば、エージェントに実際のインフラストラクチャへのアクセスを与えることは、はるかに恐れなくなり、著しく有用になります。