Elastic Cloud ServerlessとElasticsearchの統合APIキーが登場

あなたがサイト信頼性エンジニア（SRE）で、Elastic Cloud Serverlessプロジェクトの成長する製品群を担当していると想像してみてください。本番環境インフラのためのElastic Observability、セキュリティ運用センター（SOC）チームのためのElastic Security、そして顧客向けアプリケーションのためのElasticsearchです。各プロジェクトにそれぞれ固有のElasticsearch APIキーがあります。継続的インテグレーションと継続的デリバリー（CI/CD）パイプラインは、これらのプロジェクトをプロビジョニング・管理するために、別のCloud APIキーが必要です。四半期ごとにローテーションの日がやってきます。各プロジェクトを順番に確認し、新しいキーを作成し、Terraformの状態を更新し、パイプラインを再デプロイし、何も見落としがないことを祈ります。午前2時にインシデントが発生し、迅速にアクセス権を取り消す必要がある場合、どのキーがどのプロジェクト、どのサービスに属しているかを特定するために、認証情報が記載されたスプレッドシートを相互参照することになります。

今日では、こうした局面でもずっとシンプルになります。Elastic Cloud APIキーが、Elastic Cloud Serverless上でElasticsearchとKibana APIに対する直接認証に使用できるようになりました。単一の認証情報を使用して、組織のリソースを管理したり、 Elasticsearchクエリ言語（ES|QL）クエリ、データ取り込み、アラートなどのデータ操作を実行したりできるようになりました。

当社がこれを構築した理由、グローバルに分散されたIDレイヤーをどのように設計して実現した方法、そしてこれがクロスプロジェクト検索の基盤をどのように築くのかを見ていきましょう。

シークレット管理の負担

信頼性の高いCI/CDパイプライン、GitOpsワークフロー、またはTerraformの自動化をデータプラットフォームに構築する際には、隠れたコストが伴います。それは、シークレットの無秩序な拡散です。

以前のモデルでは、開発者は断片的な認証プロセスに直面していました。

• コントロールプレーン（Elastic Cloud APIキー）： Elastic Cloud API経由でプロジェクトの作成、ユーザーの招待、課金管理などを行う際に使用する組織スコープのキー。
• データプレーン（Elasticsearch APIキー）：特定のサーバーレスプロジェクト内で作成され、ElasticsearchおよびKibana APIとやり取りするために使用されるプロジェクトスコープのキー。

つまり、導入スクリプトがElastic Cloudに対して認証を行い、Serverlessプロジェクトをプロビジョニングし、その特定のプロジェクトから新しく作成されたElasticsearch APIキーを抽出し、その後、その2番目のキーを下流のアプリケーションまたは自動化ツールに注入する必要があったことになります。結果として複雑なパイプライン、断片化された監査ログ、認証情報漏洩のリスクの増加につながっていました。

Elastic Cloud Serverlessでの統合認証

このリリースにより、サーバーレスプロジェクトの分割はなくなりました。クラウド、Elasticsearch、Kibana APIsに対して明示的に認可されたElastic Cloud APIキーを作成できるようになりました。

• 以前：Elastic Cloud APIキーは、厳密にはコントロールプレーントークンでした。プロジェクトの作成、請求管理、ユーザー招待は可能だったが、プロジェクト内でElasticsearchやKibanaのAPIを呼び出せないという明確な制限がありました。データ操作には、常にプロジェクト固有の2つ目のキーが必要でした。
• 現在：Elastic Cloud APIキーを作成する際にCloud、Elasticsearch、Kibana APIへのアクセスを選択することで、Serverlessの境界が解除され、そのAPIキーが真に統一された認証情報となります。組織のインフラを管理する能力を維持しながら、同時に任意の認可されたサーバーレスプロジェクトでデータをクエリ、取り込み、分析するためのネイティブアクセスを獲得できます。

これを単一のElastic Cloud APIキーに統合することで、スコープ、監査、ローテーション、取り消しを1つのユニットとして行うことができる単一のIDが得られます。新しいプロジェクトのプロビジョニングであれ、ES|QLクエリの実行であれ、すべてのAPI呼び出しは監査ログに同じ認証情報で記録されるため、インシデント調査やコンプライアンスレビューの際に追跡できる単一の履歴が提供されます。認証情報のローテーションは、分離されたコントロールプレーンとデータプレーンのシークレット間での調整された更新ではなく、ワンステップの操作になります。また、役割の割り当てはプロジェクトごとに行われるため、1つのキーで複数のプロジェクトを横断的に管理でき、監視プロジェクトでのデータ取り込みを管理したり、セキュリティプロジェクトでクエリを実行したりすることが可能になり、プロジェクトごとに個別の認証情報を管理する手間が省けます。

重要なのは、統一されているということは決して全能であることを意味しない点です。role_assignments ペイロードを使用することで、統一されたキーを厳密に単一のプロジェクトと特定のロール（例: 読み取り専用）にスコープすることができ、認証情報が漏洩した場合でも、影響範囲を完全に制限することができます。開発者が退職した場合やアプリケーションが廃止された場合も、Elastic Cloudコンソールから単一のキーを取り消すことで、コントロールプレーンと関連するすべてのElasticsearchプロジェクトへのアクセスを即座に停止できます。

（注：Elastic Cloud Hosted/マネージド導入では、Cloud APIキーは依然としてコントロールプレーンのみを管理します。ホスト型スタックAPIへの対応は今後のリリースで予定されています。）

ワークフローの自動化

始めるのは簡単です。Elastic Cloudコンソールから完全に設定するか、Elastic Cloud APIを使って自動化できます。

UIの操作手順は変わりませんが、プロジェクトロールの割り当て時にCloud、Elasticsearch、Kibana APIへのアクセスを選択できるようになりました。

Elastic Cloud APIを使用してプログラムで統合キーを作成する方法を以下に示します。application_roles配列に注目してください。これが、Elasticsearch データプレーンへのキーのネイティブアクセスを許可します。

一度作成すると、このまったく同じキーをAuthorization: ApiKeyヘッダーでapi.elastic-cloud.comと特定のサーバーレスElasticsearchエンドポイントの両方に渡すだけです。

内部構造：分散型IDレイヤーの構築

Cloud APIキーをコントロールプレーンとデータプレーンの両方で使えるようにするのは、トークンを渡すほど単純ではありません。分散システムの根本的な課題を解決する必要があります。

歴史的に、Cloud APIキーは中央集権的なグローバルセキュリティクラスターに存在していました。これは、より高いレイテンシが許容されるコントロールプレーン操作には問題なく機能しますが、Elasticsearchのデータリクエストには超低レイテンシが求められます。すべての検索クエリやデータ取り込みリクエストを検証するために、地球を横断して中央コントロールプレーンまで往復する余裕はありません。

この問題を解決するため、グローバルに分散されたデータストアを基盤とする新しい認証アーキテクチャを導入しました。次のシーケンス図は、Elastic Cloud APIキーを使用してクライアントがElasticsearchクエリを送信する流れを示しています。グローバルコントロールプレーンへの往復なしに、認証がローカルリージョン内で完結することを示しています。Elasticsearchは認証を地域IAMサービスに委任します。このサービスはキーを検証し、グローバルに分散されたデータベースのローカルレプリカに照らしてロール割り当てを解決します。認可されると、Elasticsearchはクエリを実行し、結果をクライアントに返します。

グローバルに分散された永続性

Elastic Cloud APIキーとそれに関連付けられたロール定義は、中央集権型のセキュリティクラスターにのみ依存するのではなく、グローバルに分散された高可用性データベースに永続的に保存されるようになりました。このデータベースは、サーバーレスプロジェクトが実際に実行されるグローバルコントロールプレーンとリージョナルデータプレーン間で、アイデンティティおよびアクセス管理（IAM）データを同期します。

地域IAMによるローカル検証

クライアントがElastic Cloud APIキーを使用してElasticsearchにリクエストを送信した場合、そのリクエストはグローバルコントロールプレーンには返されません。代わりに、新しい地域IAMサービスにルーティングされます。ローカルデータベースのレプリカに対してキーを検証することで、認証がほぼゼロ遅延で行われ、グローバルなコントロールプレーンの障害から完全に隔離されることを保証します。

動的ロールマッピング

認証は戦いの半分に過ぎず、システムはリクエストを承認する必要もあります。地域IAMサービスは、クラウドレベルのロール割り当て（例：application_roles）をネイティブのElasticsearch権限に即座に変換します。Elasticsearch は、ローカルで.securityインデックスを必要とすることなく、ローカルでリクエストを承認し、実行することができます。

プロジェクト横断検索の基礎

この分散型IDアーキテクチャは、Elastic Platformの将来を支える基本的な構成要素です。

IDとアクセス権限が統一され、グローバルに同期されたことで、異なるプロジェクト間で安全に身元情報をやり取りするために必要なフレームワークが整いました。これにより、Serverless向けのプロジェクト横断検索（CPS）機能が有効になります。

CPSを使用すると、セキュリティとオブザーバビリティのワークロードを組み合わせるなど、複数のリモートServerlessプロジェクトにまたがるデータを、あたかも1つのデータセットであるかのように簡単にクエリできるようになります。統一されたAPIキーを利用することで、システムはすべてのプロジェクトにわたるユーザーの権限を同時に自動的に評価できます。対象プロジェクトごとに複雑な信頼関係、証明書、重複した認証情報を設定する必要はありません。

詳しくはこちら

スタックを簡素化する準備はできていますか？

• スタックアクセスの割り当て方法についてはElastic Cloud APIキーのドキュメントをお読みください。
• キー生成を自動化するには、「APIキーを作成する（Elastic Cloud API）」のリファレンスを参照してください。
• Elasticプラットフォーム全体で使用されているキーの種類を包括的に比較するには、 Elastic APIキーに関するドキュメントを参照してください。

Elastic Cloudでの構築を今すぐ開始または継続しましょう。

免責事項

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。