cloud-access-management

クラウドアクセス管理

Elastic Cloud 組織と Serverless プロジェクトの ID とアクセスを管理します。ユーザーの招待、定義済みまたはカスタムロールの割り当て、Cloud API キーの管理を行います。

前提条件： このスキルでは、cloud-setup スキルがすでに実行済みであり、環境内に EC_API_KEY が設定され、組織のコンテキストが確立されていることを前提とします。EC_API_KEY がない場合は、まず cloud-setup を呼び出すようエージェントに指示してください。API キーをユーザーに直接尋ねないでください。

プロジェクトの作成については、cloud-create-project スキルを参照してください。プロジェクトの日常的な操作（一覧表示、更新、削除）については、cloud-manage-project を参照してください。Elasticsearch レベルのロール管理（ネイティブユーザー、ロールマッピング、DLS/FLS）については、elasticsearch-authz スキルを参照してください。

API エンドポイントとリクエストスキーマの詳細については、references/api-reference.md を参照してください。

実行するタスク

• ユーザーを組織に招待し、Serverless プロジェクトのロールを割り当てる
• 組織メンバーと現在のロール割り当てを一覧表示する
• ユーザーのロール（組織レベルまたはプロジェクトレベル）を更新する
• 組織からユーザーを削除する
• スコープ付きロールと有効期限を設定した追加の Cloud API キーを作成する
• Serverless プロジェクト上の Elasticsearch および Kibana API も呼び出せる Cloud API キーを作成する
• Cloud API キーを一覧表示して、無効化する
• ES クラスター、インデックス、Kibana の権限を持つカスタムロールを Serverless プロジェクト内に作成する
• Cloud API の application_roles を使用して、Serverless プロジェクト上のユーザーにカスタムロールを割り当てる、または削除する
• 自然言語によるアクセス要求を、招待、ロール、API キーのタスクに変換する

前提条件と権限

項目	説明
EC_API_KEY	Cloud API キー（cloud-setup によって設定されます）。すべての操作で必要です。
Organization ID	GET /organizations を使用して自動検出されます。ユーザーに尋ねないでください。
Project endpoint	Serverless プロジェクトの Elasticsearch エンドポイントです。カスタムロールの操作でのみ必要です。
ES credentials	プロジェクトで manage_security 権限を持つ API キーまたは認証情報です。カスタムロールでのみ必要です。
Org owner role	Cloud API キーを作成および管理できるのは組織の所有者のみです。API キーの操作で必要です。

操作を実行する前に python3 skills/cloud/access-management/scripts/cloud_access.py list-members を実行し、EC_API_KEY が有効であることを確認して、組織 ID を自動検出してください。

操作レベルの権限

Elastic Cloud Serverless で一般的なアクセス管理操作を行うには、次の権限が必要です。

操作	必要な権限
メンバーの招待／削除	組織の所有者（organization-admin）
ロールの割り当てまたは削除	組織の所有者（organization-admin）
Cloud API キーの作成／無効化	組織の所有者（organization-admin）
メンバー、招待、またはキーの一覧表示	組織の任意のメンバー
カスタムロールの作成／削除	プロジェクトの ES エンドポイントに対する manage_security クラスター権限

このスキルでは、ロールの事前確認は別途行いません。要求された操作を試み、API による認可に任せてください。API から認可エラー（例：403 Forbidden）が返された場合は、処理を中止し、指定された API キーの権限を確認するようユーザーに依頼してください。

手動セットアップのフォールバック（cloud-setup が利用できない場合）

このスキルが単独でインストールされていて、cloud-setup が利用できない場合は、コマンドを実行する前に Cloud の 環境変数を手動で設定するようユーザーに案内してください。API キーをチャットに貼り付けるよう求めてはいけません。

変数	必須	説明
EC_API_KEY	はい	Organization owner ロールを持つ Elastic Cloud API キーです。
EC_BASE_URL	いいえ	Cloud API のベース URL です（デフォルト：https://api.elastic-cloud.com）。
ELASTICSEARCH_URL	条件付き	Elasticsearch の URL です。カスタムロールの操作でのみ必要です。
ELASTICSEARCH_API_KEY	条件付き	manage_security 権限を持つ Elasticsearch API キーです。カスタムロールの操作でのみ必要です。

注： EC_API_KEY が設定されていない場合、またはユーザーがまだ Cloud API キーを持っていない場合は、Elastic Cloud API keys でキーを作成してから、以下の手順でローカルに設定するよう案内してください。

推奨方法（エージェント向け）：プロジェクトのルートに .env ファイルを作成します。

EC_API_KEY=your-api-key
EC_BASE_URL=https://api.elastic-cloud.com
# Only needed for custom role operations against the project Elasticsearch endpoint:
# ELASTICSEARCH_URL=https://<project-id>.es.<region>.elastic-cloud.com
# ELASTICSEARCH_API_KEY=<your-es-manage-security-api-key>

すべての cloud/* スクリプトは、作業ディレクトリから .env を自動的に読み込みます。

代替方法：ターミナルで直接エクスポートします。

export EC_API_KEY="<your-cloud-api-key>"
export EC_BASE_URL="https://api.elastic-cloud.com"
# Only needed for custom role operations against the project Elasticsearch endpoint:
# export ELASTICSEARCH_URL="https://<project-id>.es.<region>.elastic-cloud.com"
# export ELASTICSEARCH_API_KEY="<your-es-manage-security-api-key>"

ターミナルでエクスポートした値は、別のシェルセッションで実行されるサンドボックス化されたエージェントから見えない場合があるため、エージェントを使用する場合は .env を優先してください。

アクセス要求の分解

ユーザーが自然言語でアクセスについて説明した場合（例：「検索プロジェクトに Alice を開発者として追加する」）、実行前に 要求を個別のタスクに分解してください。

ステップ 1 — 要素を特定する

要素	確認する内容
対象者	新しい組織メンバー（招待）か、既存メンバー（ロールの更新）か？
対象	どの Serverless プロジェクトか、組織レベルのアクセスか？
アクセスレベル	定義済みロール（Admin／Developer／Viewer／Editor）か、カスタムロールか？
API キー？	プログラムによるアクセス用の Cloud API キーも必要か？

ステップ 2 — 定義済みロールで対応できるか確認する

以下の定義済みロールの表を参照してください。定義済みロールを優先し、必要な粒度を満たす定義済みロールがない場合に限り、カスタムロールを作成してください。

ステップ 3 — 既存の状態を確認する

作成または招待する前に、すでに存在するものを確認してください。

python3 skills/cloud/access-management/scripts/cloud_access.py list-members
python3 skills/cloud/access-management/scripts/cloud_access.py list-api-keys

ユーザーがすでにメンバーの場合は、招待を省略し、代わりにロールを更新してください。

API キーの要求について、Cloud API キーを作成および管理できるのは Organization owner のみです。認証済みユーザーに organization-admin ロールがない場合、API キーの操作は 403 エラーで失敗します。list-api-keys が返す既存のキーを確認してください。同じ目的またはタスクに対して、有効なキーがすでにあり、必要なロールを持ち、十分な有効期間が残っている場合は、新しいキーを作成する代わりに再利用してください。異なる目的（たとえば、別々の CI パイプライン）に使用するのであれば、権限が同じキーが 2 つあっても問題ありません。しかし、同じタスク用に 2 つ目のキーを作成する必要はなく、管理の負担が増えるだけです。

ステップ 4 — 実行する

skills/cloud/access-management/scripts/cloud_access.py の適切なコマンドを実行してください。メンバーの削除やキーの失効といった破壊的な操作は、実行前にユーザーに確認してください。

ステップ 5 — 検証する

実行後、メンバーまたはキーを再度一覧表示し、変更が反映されたことを確認してください。

定義済みロール

組織レベルのロール

ロール	Cloud API role_id	説明
組織オーナー	organization-admin	組織、デプロイメント、プロジェクトに対する完全な管理権限
請求管理者	billing-admin	請求情報のみを管理

サーバーレスのプロジェクトレベルのロール

ロール	Cloud API role_id	利用可能なサービス	説明
管理者	admin	Search、Obs、Security	プロジェクトの完全な管理権限、サインイン時のスーパーユーザー
開発者	developer	Search のみ	インデックス、API キー、コネクター、ビジュアライゼーションの作成
閲覧者	viewer	Search、Obs、Security	プロジェクトのデータと機能への読み取り専用アクセス
編集者	editor	Obs、Security	プロジェクト機能の設定、データインデックスへの読み取り専用アクセス
Tier 1 アナリスト	t1_analyst	Security のみ	アラートのトリアージ、一般的な読み取り、ダッシュボードの作成
Tier 2 アナリスト	t2_analyst	Security のみ	アラートのトリアージ、調査の開始、ケースの作成
Tier 3 アナリスト	t3_analyst	Security のみ	詳細な調査、ルール、リスト、対応アクション
SOC マネージャー	soc_manager	Security のみ	アラート、ケース、エンドポイントポリシー、対応アクション
ルール作成者	rule_author	Security のみ	検知エンジニアリング、ルールの作成

プロジェクトレベルのロールは、招待時（POST /organizations/{org_id}/invitations）またはロール割り当ての更新（POST /users/{user_id}/role_assignments）で割り当てます。project スコープを含む role_assignments の JSON スキーマについては、references/api-reference.md を参照してください。

カスタムロール（サーバーレス）

事前定義されたロールでは必要な細分化ができない場合は、Elasticsearch security API を使用してサーバーレスプロジェクト内にカスタムロールを作成し、Cloud API の application_roles フィールドを通じてユーザーに割り当てます。

セキュリティ：カスタムロールを使用する場合、事前定義された Cloud ロールを別途割り当てないでください。 カスタムロールは、プロジェクトスコープに対する Viewer レベルの Cloud アクセス権を暗黙的に付与します。同じプロジェクトに対して viewer（またはその他の事前定義されたロール）も別の Cloud ロール割り当てとして設定すると、ユーザーが SSO でプロジェクトにサインインしたとき、両方のロールの権限が統合されます。Viewer のスタックロールはほとんどのカスタムロールよりも広範な権限を持つため、意図した制限が上書きされます。

カスタムロールの割り当て方法

• 事前定義ロール（viewer、developer、admin など）は、Cloud API（invite-user、assign-role）を通じて割り当てます。ユーザーが SSO でプロジェクトにログインすると、Cloud ロールに対応するスタックロールが付与されます（たとえば、Cloud の viewer は viewer スタックロールに対応します）。
• カスタムロールは、Elasticsearch セキュリティ API（create-custom-role）を通じてプロジェクト内に作成し、Cloud API の application_roles フィールド（assign-custom-role）を通じて割り当てます。application_roles を設定すると、SSO 時にユーザーに付与されるのは指定したカスタムロール のみ であり、Cloud ロールに対応するデフォルトのスタックロールは付与されません。
• assign-custom-role コマンドは、role_id をプロジェクトタイプに応じた Viewer ロール（elasticsearch-viewer、observability-viewer、または security-viewer）に設定し、application_roles をカスタムロール名に設定します。これにより、ユーザーは Cloud コンソールでプロジェクトを表示してアクセスできますが、プロジェクト内で受け取るのは、権限が制限されたカスタムロールのみになります。
• Cloud API キーでも application_roles を使用して、Serverless プロジェクトの ES／Kibana API にアクセスできます。詳しくは、下記のCloud API キー — ES および Kibana API アクセスを参照してください。

カスタムロールの標準的なオンボーディング手順

1. プロジェクト内にカスタムロールを作成します（create-custom-role）。
2. ユーザーがまだ組織のメンバーでない場合は、組織に招待します（invite-user）。招待にプロジェクトロールの割り当てを含めないでください。次の手順でカスタムロールを割り当てることで、プロジェクトへのアクセスが設定されます。
3. ユーザーにカスタムロールを割り当てます（assign-custom-role --user-id ... --project-id ... --custom-role-name ...）。
4. list-members と list-roles で確認します。

カスタムロールを作成する

python3 skills/cloud/access-management/scripts/cloud_access.py create-custom-role \
  --role-name marketing-analyst \
  --body '{"cluster":[],"indices":[{"names":["marketing-*"],"privileges":["read","view_index_metadata"]}]}'

これは、プロジェクトの Elasticsearch エンドポイントで PUT /_security/role/{name} を呼び出します。

名前の制約

ロール名は英字または数字で始まり、英字、数字、_、-、. のみを含める必要があります。Serverless では Run-as 権限を使用できません。

カスタムロールと事前定義ロールの使い分け

シナリオ	使用するロール
標準的な管理者／開発者／閲覧者のアクセス	事前定義ロール
特定のインデックスパターンへの読み取り専用アクセス	カスタムロール
DLS または FLS による制限	カスタムロール
Kibana の機能レベルのアクセス制御	カスタムロール

高度な DLS／FLS パターン（テンプレート化されたクエリ、ABAC）については、elasticsearch-authz スキルを参照してください。

Cloud API キー — ES および Kibana API アクセス

Cloud API キーで、Cloud API に加えて、Serverless プロジェクトの Elasticsearch および Kibana API にもオプションでアクセスできるようになりました。これにより、コントロールプレーン（Cloud API）とデータプレーン（ES／Kibana API）の操作に単一の認証情報を使用できます。たとえば、Cloud API でプロジェクトを作成し、続けて ES API でデータをインデックス化する CI パイプラインで利用できます。

仕組み

キーの作成時に、role_assignments に application_roles を追加します。このフィールドには、事前定義ロール名（admin、developer、viewer、および t1_analyst、editor などのソリューション固有のロール）や、プロジェクト内で PUT /_security/role/{name} によって作成されたカスタムロール名を配列で指定できます。事前定義ロールは、デフォルトですべてのプロジェクトで使用できます。キーがアクセスする各プロジェクト内でカスタムロールを個別に作成する必要があります。参照先のカスタムロールがプロジェクト内に存在しない場合、そのキーはそのプロジェクトでアクセス権を付与されませんが、エラーは表示されません。

重要なルール：暗黙の継承はありません

ユーザーとは異なり、API キーは role_id からスタックロールを 継承しません。application_roles を省略するか空にすると、キーに付与されるのは Cloud API へのアクセスのみです。このキーで ES または Kibana のエンドポイントを呼び出すと、403 Forbidden が返されます。これは後方互換性のための仕様です。既存の application_roles を持たないキーは、引き続き Cloud 専用キーとして機能します。

スコープモード

• プロジェクトスコープ（推奨） — 特定のプロジェクト、または指定した種類のすべてのプロジェクトへのアクセスを許可します。各エントリの application_roles とともに、role_assignments の project キーを使用します。ユーザーがプロジェクトをまたぐアクセスを明示的に必要としている場合を除き、デフォルトではこちらを使用してください。

• 組織スコープ — 組織内の現在および将来のすべてのプロジェクトへのアクセスを許可します。application_roles とともに、role_assignments の organization キーを使用します。データプレーンで設定できる最も広範なスコープです。 キーがすべてのプロジェクトにアクセスする必要が本当にある場合（たとえば、プラットフォームの自動化や組織全体を対象としたプロジェクト横断検索）に限り使用してください。application_roles を設定した組織スコープのキーを作成する前に、必ずユーザーに確認してください。まだ存在しないプロジェクトにも ES／Kibana へのアクセスが許可されるためです。

カスタムロールと組織スコープのアクセス： 組織スコープの割り当てで application_roles にカスタムロール名を使用する場合、そのキーにアクセスさせたい各プロジェクトにカスタムロールが存在している必要があります。プロジェクトにそのカスタムロールが定義されていない場合（PUT /_security/role/{name} で設定）、キーはそのプロジェクトへのアクセス権を暗黙のうちに付与されません。エラーも発生しません。組織全体へのアクセスには、デフォルトですべてのプロジェクトで利用できる定義済みロール（admin、developer、viewer）を優先してください。複数のプロジェクトでカスタムロールを使用する必要がある場合は、対象プロジェクトごとにあらかじめロールを作成してください。

エージェント向けガイダンス： ユーザーから ES／Kibana へのアクセス権を持つ API キーを求められた場合は、デフォルトでプロジェクトスコープの割り当てを使用してください。組織内のすべてのプロジェクトへのアクセスをユーザーが明示的に必要としている場合に限り、組織スコープの application_roles を提案してください。続行する前に、意図を確認してください。組織スコープのアクセスは将来のプロジェクトにも適用されます。ユーザーが組織スコープのアクセスにカスタムロール名を指定した場合、そのロールをプロジェクトごとに個別に定義する必要があることを伝えてください。

例

開発者 ES アクセス権を持つプロジェクトスコープのキー（便利な --stack-access フラグを使用）：

python3 skills/cloud/access-management/scripts/cloud_access.py create-api-key \
  --description "CI pipeline - ES ingest" \
  --expiration 30d \
  --roles '{"project":{"elasticsearch":[{"role_id":"developer","organization_id":"$ORG_ID","all":true}]}}' \
  --stack-access developer

管理者 ES アクセス権を持つ組織スコープのキー（すべてのプロジェクトへのアクセス — 注意して使用してください）：

python3 skills/cloud/access-management/scripts/cloud_access.py create-api-key \
  --description "Platform automation" \
  --expiration 7d \
  --roles '{"organization":[{"role_id":"organization-admin","organization_id":"$ORG_ID"}]}' \
  --stack-access admin

カスタムロールを持つプロジェクトスコープのキー（生の JSON）：

python3 skills/cloud/access-management/scripts/cloud_access.py create-api-key \
  --description "Marketing ETL" \
  --expiration 14d \
  --roles '{"project":{"elasticsearch":[{"role_id":"elasticsearch-viewer","organization_id":"$ORG_ID","all":false,"project_ids":["$PROJECT_ID"],"application_roles":["marketing-writer"]}]}}'

$ORG_ID と $PROJECT_ID を実際の組織 ID とプロジェクト ID に置き換えてください。組織 ID を確認するには list-members を使用します。

よくある間違い： ES または Kibana のエンドポイントを呼び出すときに API キーで 403 が返される場合、最も可能性の高い原因は application_roles が設定されていないことです。ユーザーとは異なり、API キーでスタックにアクセスするには、明示的に application_roles を設定する必要があります。role_id だけでは不十分です。

例

検索プロジェクトに閲覧者としてユーザーを招待する

プロンプト： 「[email protected] を、読み取り専用アクセス権で検索プロジェクトに追加してください。」

python3 skills/cloud/access-management/scripts/cloud_access.py invite-user \
  --emails [email protected] \
  --roles '{"project":{"elasticsearch":[{"role_id":"viewer","organization_id":"$ORG_ID","all":false,"project_ids":["$PROJECT_ID"]}]}}'

$ORG_ID と $PROJECT_ID を実際の ID に置き換えてください。招待が承諾された時点で閲覧者ロールが割り当てられます。カスタムロールへのアクセスには、ユーザーが招待を承諾した後に assign-custom-role を使用してください。同じプロジェクトに対して、定義済みロールの割り当てとカスタムロールを併用しないでください。

CI/CD API キーを作成する

プロンプト： 「デプロイメントすべてへの編集者アクセス権を持ち、30 日後に期限切れとなる、CI パイプライン用の API キーを作成してください。」

python3 skills/cloud/access-management/scripts/cloud_access.py create-api-key \
  --description "CI/CD pipeline" \
  --expiration "30d" \
  --roles '{"deployment":[{"role_id":"deployment-editor","all":true}]}'

実際のキー値は、セキュアな一時ファイル（アクセス権限 0600）に書き込まれます。標準出力の JSON には、生のシークレットではなく _secret_file のパスが含まれます。キーは一度しか表示されないため、そのファイルから取得するようユーザーに伝えてください。CI パイプラインでこのキーが不要になったら、未使用のキーが蓄積しないよう、delete-api-key を使用して取り消してください。

ES アクセス権を持つ CI/CD API キーを作成する

プロンプト：「検索プロジェクトにデータをインデックス登録できる、CI パイプライン用の API キーを作成してください。」

python3 skills/cloud/access-management/scripts/cloud_access.py create-api-key \
  --description "CI pipeline - ES ingest" \
  --expiration 30d \
  --roles '{"project":{"elasticsearch":[{"role_id":"developer","organization_id":"$ORG_ID","all":true}]}}' \
  --stack-access developer

$ORG_ID を実際の組織 ID に置き換えてください。--stack-access フラグを指定すると、ロール割り当てに application_roles: ["developer"] が挿入され、すべての Elasticsearch プロジェクトで、このキーに開発者レベルの ES/Kibana API アクセス権が付与されます。--stack-access も JSON 内の明示的な application_roles も指定しない場合、このキーには Cloud API へのアクセス権のみが付与され、ES/Kibana の呼び出しでは 403 が返されます。

マーケティングデータ用のカスタムロールを作成する

プロンプト：「検索プロジェクトの marketing-* インデックスに読み取り専用でアクセスできるロールを作成してください。」

python3 skills/cloud/access-management/scripts/cloud_access.py create-custom-role \
  --role-name marketing-reader \
  --body '{"cluster":[],"indices":[{"names":["marketing-*"],"privileges":["read","view_index_metadata"]}]}'

次に、assign-custom-role コマンドを使ってカスタムロールをユーザーに割り当てます。このコマンドは Cloud API のロール割り当てに application_roles を設定します。

読み取り専用ダッシュボード用のカスタムロール設定手順全体

プロンプト：「検索プロジェクトに [email protected] を追加し、ダッシュボードへの読み取り専用アクセス権を付与してください。」

# 1) Create custom role in the project
python3 skills/cloud/access-management/scripts/cloud_access.py create-custom-role \
  --role-name dashboard-reader \
  --body '{"cluster":[],"indices":[],"applications":[{"application":"kibana-.kibana","privileges":["feature_dashboard.read"],"resources":["*"]}]}'

# 2) Invite user to the organization (no project roles — custom role handles access)
python3 skills/cloud/access-management/scripts/cloud_access.py invite-user \
  --emails [email protected]

# 3) After invitation is accepted, assign the custom role via application_roles
python3 skills/cloud/access-management/scripts/cloud_access.py assign-custom-role \
  --user-id "$USER_ID" \
  --project-id "$PROJECT_ID" \
  --project-type elasticsearch \
  --custom-role-name dashboard-reader

ユーザーには Viewer レベルの Cloud アクセス権（コンソールでプロジェクトを表示できます）が付与され、プロジェクトに SSO でログインした際には dashboard-reader の権限のみが付与されます。このプロジェクトには、Cloud ロールとして別途 viewer も割り当てないでください。 割り当てると、より広範な Viewer スタックロールが付与され、カスタムロールの制限が無効になります。

ユーザーのプロジェクトロールを更新する

プロンプト：「Bob をオブザーバビリティプロジェクトの admin に昇格させてください。」

python3 skills/cloud/access-management/scripts/cloud_access.py assign-role \
  --user-id "$USER_ID" \
  --roles '{"project":{"observability":[{"role_id":"admin","organization_id":"$ORG_ID","all":false,"project_ids":["$PROJECT_ID"]}]}}'

$USER_ID、$ORG_ID、$PROJECT_ID を実際の値に置き換えてください。ユーザー ID を調べるには list-members を使います。ロール割り当てを 削除するには、同じ --roles スキーマを指定して remove-role-assignment を使います。

すべてのメンバーとそのロールを一覧表示する

プロンプト：「組織にアクセスできるユーザーを表示してください。」

python3 skills/cloud/access-management/scripts/cloud_access.py list-members

出力には、各メンバーのユーザー ID、メールアドレス、割り当てられたロールが含まれます。

ガイドライン

• EC_API_KEY が設定されていない場合、ユーザーに入力を求めず、まず cloud-setup を呼び出すようエージェントに指示します。
• メンバーの削除やキーの無効化など、破壊的な操作を実行する前に、必ずユーザーに確認します。
• アクセス要件を満たす場合は、カスタムロールより定義済みロールを優先します。
• ここで作成する API キーは、CI/CD、スコープを限定したアクセス、チームメンバー向けの追加キーです。初期キーは cloud-setup で管理します。
• シークレットが stdout または stderr に出力されることはありません。 スクリプトは機密フィールド（key、token、invitation_token）を REDACTED というプレースホルダーに置き換えて stdout に出力し、完全な応答を 0600（所有者のみ読み取り可能）の権限を持つ一時ファイルに書き込みます。stdout の JSON には、そのファイルを示す _secret_file パスが含まれます。シークレットファイルの内容を読み取ったり、抽出したり、要約したりしないでください。 ユーザーからキーを求められた場合は、_secret_file パスにあるファイルを開くよう伝えます。ユーザーがシークレットを取得した後、ファイルを削除するよう案内します。
• Cloud API キーは作成時のロールを引き継ぎ、後から更新できません。ロールを変更するには、キーを無効化して再作成します。
• API キーの適切な管理 — 最小化し、スコープを限定し、有効期限を設定する：
  • キーを作成する前に、必ず list-api-keys を実行し、同じ目的またはタスクに使用する既存のキーが、必要なロールと十分な残りの有効期間を備えているか確認します。権限が同一でも、異なる目的（たとえば、別々の CI パイプライン）に使用するキーは正当です。同じタスクに対する重複キーを避けることが目的です。
  • タスクの想定期間に合った --expiration を必ず設定します。短期間のタスク（CI の実行、一度限りの移行）には、短期間のキー（例：1d、7d）を使用します。
  • タスクの完了後、不要になったキーを delete-api-key で無効化するようユーザーに促します。これは短期間のキーと長期間のキーの両方に適用されます。
  • 長期間使用するキー（例：監視パイプライン）にも有効期限を設定し、無期限にするのではなく定期的にローテーションします。
• 各組織で有効にできる API キーは最大 500 個です。デフォルトの有効期限は 3 か月です。
• 招待のデフォルトの有効期限は 72 時間です。ユーザーが承諾していない場合は、招待を再送信します。
• SAML SSO の設定については、Elastic Cloud SAML docs を参照してください。
• カスタムロールのセキュリティ — 過剰な権限付与を避ける： assign-custom-role を使用して同じプロジェクトにカスタムロールを割り当てる場合、定義済みの Cloud ロール（例：viewer）を絶対に割り当てないでください。カスタムロールの割り当てでは、暗黙的に Viewer レベルの Cloud アクセスが付与されます。定義済みロールを追加すると、ユーザーのプロジェクト内の権限がカスタムロールで意図した範囲を超えて拡大します。
• カスタムロールが存在するのにユーザーがプロジェクトにアクセスできない場合は、ロールが assign-custom-role（Cloud API の application_roles を使用）で割り当てられていることを確認します。カスタムロールを作成しただけではプロジェクトへのアクセス権は付与されません。Cloud API での割り当てが必要です。
• ネットワークレベルのセキュリティ（トラフィックフィルター、プライベートリンク）については、cloud-network-security スキルを参照してください。
• Cloud ロール以外の ES レベルのロール管理（ネイティブユーザー、DLS/FLS）については、elasticsearch-authz を参照してください。