Fleet Controlアクセスの管理

このガイドでは、Fleet Controlの操作に対するロールベースのアクセス制御（RBAC）を設定するためのパターンを提供します。基本的なものからエンタープライズ向けまで、3つの実装パターンをUIとNerdGraphの両方の例とともに説明します。

どのアプローチが組織に適していますか？

組織の分離（推奨）：複数の自律的なビジネスユニットを管理している場合、またはユニット間の可視性をゼロにして厳格な請負業者の分離が必要な場合は、マルチテナンシー（個別のNew Relic組織）を使用します。これにより、複雑なカスタムロールを使用せずに、完全な境界の適用が提供されます。「複数のビジネスユニットでのFleet Controlの委任」にジャンプします。
単一組織のRBAC：契約、請求、または運用上の制約により単一の組織が必要な場合は、このガイドのRBACパターン（Basic、Advanced、またはEnterprise）を使用します。注意：ユーザーは組織全体に他のフリートが存在することを引き続き確認でき、中央IT部門は新しいフリートごとにアクセス権限を作成する必要があります。

前提条件

以下のパターンのいずれかを設定する前に：

フルプラットフォームユーザー：すべてのFleet Control権限には、フルプラットフォームのユーザータイプが必要です。
Proまたはエンタープライズエディション：これらのパターンで使用するカスタムロールとカスタムグループを作成するために必要です。
認証ドメインマネージャーロール：Authentication domain managerロールを持つユーザーは、特定のフリートにグループとロールを割り当てるアクセス付与を作成できます。これは、すべてのアクセス付与操作に対するNew Relicプラットフォームの要件です。
初期Agent Controlセットアップ：システムIDを作成するために、1回だけAuthentication domain managerロールが必要です。
フリートと設定の作成：Organization product adminロールが必要です。このロールは、デフォルトのUserグループの全員に自動的に付与されます。
デプロイメントの実行：Organization Managerロールが必要です。このロールは、デフォルトのAdminグループの全員に自動的に付与されます。または、Fleet managerロール、あるいはDeployを持つカスタムロールを使用すると、組織全体に影響を与えることなく、特定のフリートに対して付与できます。

ロール要件に関するよくある誤解

多くのチームは、すべてのFleet Control操作にAuthentication domain managerが必要であると思い込んでいます。これは事実ではありません。

Authentication domain manager 以下の場合にのみ必要です：

初期Agent Controlセットアップ（1回限り）。これによりシステムIDが作成されます。
アクセス権限の作成。これにより、グループをフリートに割り当てます。
継続的なフリート管理（フリートの作成や設定の作成など）にはOrganization product adminのみが必要であり、ほとんどのユーザーはすでにこれを持っています。

Fleet Controlの権限の構成方法

カスタムロールを作成すると、Fleet Controlの権限が表として表示されます：リソースの行と、Read、Modify、Delete、およびOtherの列です。各チェックボックスは、個別の権限ではなく、関連する一連のアクションを付与します。表示される行は、ロールのスコープによって異なります。

組織スコープのロールにはFleets (all)行があり、組織内のすべてのフリートを対象とします：

許可	対象範囲
Read	フリート、管理対象エンティティ上のエージェント、設定とその内容、フリートのメンバーシップ、および承認ポリシーの表示
Modify	フリートの作成と更新、設定の作成とバージョンの追加、およびReadのすべての機能
Delete	フリート、設定、およびデプロイメントの削除
Other: Deploy	デプロイメントの作成、編集、実行、削除、およびフリート内の管理対象エンティティの変更
Other: Approve configurations	設定バージョンの承認、変更リクエスト、または拒否
Other: Configure organization governance	承認ポリシーを設定および変更します。

フリートを対象とするエンティティスコープのロールにはFleets (individual)行が表示され、ロールが付与されているフリートのみをカバーします：

許可	対象範囲
Modify	フリートの名前変更、説明の編集、およびメンバーシップの表示
Delete	フリートの削除
Other: Deploy	フリートのデプロイメントを作成、編集、実行、および削除し、そこに含まれる管理対象エンティティを変更します。

フリートスコープのロールは、読み取りアクセスを置き換えるのではなく、その上に構築されます。

Fleets (individual)の行にはRead権限がありません。フリートスコープのロールは、フリートに対してアクションを実行する機能を付与するものであり、そもそもFleet Controlを表示するためのものではありません。

ユーザーは組織スコープのロールからの読み取りアクセス権も必要ですが、通常はデフォルトのUserグループを通じてこのアクセス権を持っています。他に何も権限を持たないメンバーのグループにフリートスコープのロールを付与した場合、そのメンバーはアクションを実行するための情報を何も表示できません。

設定の承認と承認ポリシーの設定は、組織スコープのロールでのみ利用できるため、承認権限を特定のフリートにスコープすることはできません。詳細については設定の承認を、付与方法については承認権限の委任をご覧ください。

基本パターン：単一フリートの権限（FGA）

Fleet Control エンティティスコープのアクセス権限を通じて、きめ細かいアクセス（FGA）をサポートします。組み込みのFleet managerロールは、特定のフリートエンティティにスコープを設定できます。これにより、Organization Managerがなくても、デプロイメントを含め、それらのフリートの完全な運用制御をグループに付与できます。

これにより、組織内のすべてのフリートへのアクセス権を付与することなく、特定のフリートを管理するアクセス権をチームに付与できます。

UIウォークスルー

フリートを作成します（まだ作成されていない場合）：
1. に行く All capabilities > New Relic Control > Fleets
2. クリック Create a fleet
3. たとえば、次のように名前を付けます production-us-east-fleets
4. フリートGUIDを保存してメモしてください。
ターゲットグループを作成または特定します：
1. に行く Administration > Access management > Groups
2. 新しいグループ（たとえばprod-us-east-fleet-operators）を作成するか、既存のグループを使用します
3. Create a groupモーダルで、Add usersドロップダウンを使用して今すぐユーザーを追加するか、後でグループを編集して追加します。
4. グループIDを控えておきます
エンティティ範囲のアクセス権の付与：
1. に行く New Relic Control > Fleets
2. フリートの行でケバブメニューを開き、次を選択してください。 Fleet permissions
3. Fleet permissionsモーダルで、グループを選択し、ロールとしてFleet managerを選択します。必要な数だけグループとロールのペアを追加します。
4. 「Save」をクリックしてください。これにより、ペアごとに1つのアクセス権限が作成されます。

フリートの権限が欠落しているか、ロックされた状態で開く場合

Fleet permissionsメニュー項目にはAuthentication domain managerロールが必要です。これがないと、アクションがフリートの行に表示されないか、モーダルが部分的に利用可能になるのではなくロックされた状態で開きます。

権限は、フリート作成時に「Create fleet」ダイアログからアタッチすることもできます。

結果：prod-us-east-fleet-operatorsのメンバーは、production-us-east-fleetsに対してのみデプロイメントを実行し、メンバーを管理できるようになります。他のフリートを変更することはできません。読み取りアクセス権は、この付与からではなく組織スコープのロールから提供されるため、他のフリートが存在することは引き続き確認できます。

NerdGraphの自動化

mutation GrantFleetAccess {
  authorizationManagementGrantAccess(
    grantAccessOptions: {
      grantee: { type: GROUP, id: "YOUR_GROUP_ID" }
      entityAccessGrants: {
        entity: { id: "YOUR_FLEET_GUID", type: "fleet" }
        roleId: "YOUR_ROLE_ID"
      }
    }
  ) {
    accessGrants {
      id
    }
  }
}

IDの見つけ方：

フリートGUID：フリート詳細ページのURLで確認するか、NerdGraph Fleet Controlチュートリアルを使用してフリートをクエリします。
グループID：Administration > Access management > Groups、グループをクリックすると、IDがURLに表示されます。
ロールID：既知の問題の回避策を使用してクエリを実行します。

高度なパターン：ライフサイクル分離のためのカスタムロール

異なるFleet Control権限を持つ2つのカスタムエンティティスコープのロールを作成し、同じフリートエンティティ上の異なるグループにそれぞれ付与します。Fleet managerには変更、削除、およびデプロイが一緒に含まれているため、グループが持つべき権限よりも大きい場合は、それを分割します。

これにより、両方のグループが同じフリートで作業しながら、フリートの定義とメンバーシップを変更できるユーザーと、デプロイメントを実行できるユーザーを分離できます。

ブループリントの例：カスタムロールの設計

このセクションでは、アーキテクチャーの権限をデプロイメントの実行から分離するために、権限の低いカスタムロールを設計する方法の推奨例を示します。

どちらのロールもエンティティスコープであり、Fleetをターゲットとします：

ロール	許可	保持者が行えること	割り当て先
`Fleet author`	Modify	フリートの名前変更、説明の編集、メンバーシップの表示	プラットフォームOpsチーム
`Fleet deployer`	Other: Deploy	デプロイメントの作成、編集、実行、および削除、フリート内の管理対象エンティティの変更	アプリチームと請負業者

Deleteはチェックを外したままにする別の権限であるため、どちらのロールもフリートを削除することはできません。

Fleet Controlの設定はフリートに属するのではなく組織レベルのオブジェクトであるため、設定の作成はどちらのロールにも含まれません。それらの作成はOrganization product adminに含まれていますが、デフォルトのUserグループはすでにこれを持っています。実際には、作成者が設定を記述し、これらのフリートをスコープとするロールが、何がどこにデプロイされるかを制御します。

UIウォークスルー

カスタムロールを作成します。それぞれについて：
1. に行く Administration > Access management > Roles
2. クリック Add a role
3. ロールのスコープにはSingle item or entityを選択し、クリックします Next
4. Select what you want to configure access toの下で、選択します。 Fleet
5. ロールに名前を付けます。たとえば、 Fleet author
6. Set permissionsでFleet Controlを展開し、Fleets (individual)行目でロールが持つものを選択します：authorロールの場合はModify、deployerロールの場合はOtherの下のDeploy。
7. 保存してから、2番目のロールについて繰り返します。
各ロールのグループを作成します：
1. 作成者用のグループfleet-architectsを作成し、Create a groupモーダルのAdd usersドロップダウンから関連するユーザーを追加するか、後でグループを編集して追加します。
2. 同じ方法で、デプロイ担当者用のグループfleet-deployment-operatorsを作成します。
各グループにエンティティスコープのアクセス権を付与する：
1. New Relic Control > Fleetsに移動し、ターゲットフリートのケバブメニューを開いて、次を選択します Fleet permissions
2. グループとロールのペアを追加します：fleet-architectsと Fleet author
3. グループとロールのペアを追加します：fleet-deployment-operatorsと Fleet deployer
4. 保存すると、両方の付与が一緒に作成されます。

カスタムロールは、新しい権限を自動的に取得しません。

カスタムロールには、アドミニストレーターが追加したもののみが含まれます。標準ロールは、新しい組織スコープの機能がリリースされるとその権限を受け取ります。そのため、後でFleet Controlが機能を追加した場合、誰かがそれらを持つべき各カスタムロールに追加する必要があります。

新しいFleet Control機能を自動的に取得する必要があるユーザーには、代わりに標準ロールを割り当てます。

NerdGraphの自動化

カスタムロールはUIで作成されます。ロールの作成には、チェックボックスに表示される権限名ではなく、内部の権限識別子が使用されるため、ロール自体を構築するための実用的なAPIパスはありません。

ロールが作成されたら、各ロールのIDを渡して、基本パターンと同じミューテーションで付与します。

結果：フリート作成者は所有するフリートを形成できますが、デプロイメントを実行することはできません。デプロイメントオペレーターはデプロイメントを実行できますが、フリートを再定義または削除することはできません。

エンタープライズパターン：委任されたグループ管理

グループメンバーシップの管理を委任するには、グループスコープの付与を持つGroup adminロールを使用します。

これにより、チームリーダーは完全なAuthentication domain manager権限を必要とせずに、チームのグループにメンバーを追加したり、グループからメンバーを削除したりできます。

UIウォークスルー

マネージャーグループの作成：
1. に行く Administration > Access management > Groups
2. グループ作成 fleet-team-leads
3. チームリーダーをメンバーとして追加してください。
ターゲットグループにグループ管理者ロールを付与します：
1. に行く Administration > Access management > Access grants
2. クリック Create new grant
3. 他のグループをターゲットとする付与タイプである、グループ付与を選択します。
4. グループを選択 fleet-team-leads
5. ロール： Group admin
6. チームリードが管理できるようにするグループを選択します。たとえばfleet-architectsおよび fleet-deployment-operators
7. 保存

結果：fleet-team-leadsのメンバーは、Authentication domain managerロールを必要とせずに、fleet-architectsおよびfleet-deployment-operatorsのユーザーを追加および削除できるようになりました。

重要な制限事項

Group admin グループに誰が含まれるかを管理できますが、新しいアクセス付与を作成したり、新しいフリートにグループを割り当てたりすることはできません。新しいフリートが作成された場合、引き続きAuthentication domain managerを持つユーザーがそのフリートのアクセス付与を作成する必要があります。

NerdGraphの自動化

mutation DelegateGroupManagement {
  authorizationManagementGrantAccess(
    grantAccessOptions: {
      grantee: { type: GROUP, id: "YOUR_TEAM_LEADS_GROUP_ID" }
      groupAccessGrants: [
        { groupId: "YOUR_TARGET_GROUP_ID", roleId: "YOUR_GROUP_ADMIN_ROLE_ID" }
      ]
    }
  ) {
    accessGrants {
      id
    }
  }
}

複数のビジネスユニットでFleet Controlを委任する

このセクションでは、複数の自律的なビジネスユニットを持ち、Fleet Controlの管理を委任する必要がある顧客で見られるシナリオの概要を説明します。上記のパターンを使用した推奨ソリューションと代替アプローチの両方を提供します。

シナリオ

例：ByteFlix Entertainmentは、単一のNew Relic組織の下で複数の自律的なビジネスユニットを運営する大規模なメディア企業です。

ByteFlix+、ストリーミングサービス
BBS、ByteFlix Broadcast System、ブロードキャストネットワーク
ケーブルネットワークのPixelTV

組織構造

中央IT：

Organization ManagerおよびAuthentication domain managerのロールを持つのは2、3人のみです。
彼らはNew Relicのライセンスとガバナンスを管理します。
監視エンティティの設定や作成は行いません。
それらはアクセス管理の変更におけるボトルネックになります

ビジネスユニット：

各ユニットは、同じNew Relic組織の下に個別のアカウントを持っています。
各ユニットは独自のオブザーバビリティを独立して管理します
多くのユニットは、New Relic Infrastructureを管理するために請負業者を使用しています

課題

ByteFlixはFleet Controlの導入を希望していますが、課題に直面しています：

厳格なビジネスユニットの分離が必要：ByteFlix+チームは、BBSまたはPixelTVのインフラストラクチャを管理してはなりません。
請負業者への委任：ユニットのリーダーは、中央のIT部門を関与させることなく、請負業者をオンボーディングする必要があります
ライフサイクルの分離：プラットフォームの運用チームがフリートを形成し、アプリチームがデプロイする必要がありますが、アプリチームがフリートを削除したり再定義したりできないようにする必要があります
広範な管理者権限の付与なし：セキュリティ上の懸念から、中央IT部門はユニットチームにAuthentication domain managerを付与しません。

推奨される解決策：別々の組織

ByteFlixの組織構造に基づくと、マルチテナンシーが理想的なソリューションです。

これが意味すること

複数のアカウントを持つ1つの組織の代わりに、ByteFlixは3つの独立したNew Relic組織を作成します：

ByteFlix+組織、独自のアカウントを持つ
BBS組織、独自のアカウントを持ちます。
PixelTV組織、独自のアカウントを持つ

各ビジネスユニットは、独立した独自のNew Relic組織になります。

利点

完全なビジネスユニットの分離：Fleet Controlを含む組織スコープの機能は、そのユニットの組織内のデータのみを表示します
ユニット間の可視性なし：組織の境界によって保証されているため、ByteFlix+ユーザーはBBSまたはPixelTVエンティティを表示できません。
自律的な管理：各ユニットには独自の認証ドメイン管理者と組織管理者がおり、他のユニットに影響を与えることはありません。
請負業者への委任：各ユニットは、中央のIT部門や他のユニットを関与させることなく、請負業者にアクセス権を付与できます
よりシンプルな権限：分離を強制するために、エンティティスコープの付与やカスタムロールは必要ありません

共有サービスについてはどうでしょうか？

New Relicのアカウント共有により、アカウントは組織の境界を越えることができます。ByteFlixに、一元化されたロギングや共有インフラストラクチャなど、ユニット全体での可視性を必要とする共有プラットフォームサービスがある場合、それらのアカウントを複数の組織で共有できます。

たとえば、中央IT部門は共有プラットフォームアカウントを持つ共有オブザーバビリティ組織を維持し、ByteFlix+、BBS、およびPixelTVの各組織はアカウント共有を介してそれらのアカウントへの読み取りアクセス権を持ちます。

トレードオフ

利点：

組織の境界によって強制される、最も強力な分離モデル
最もシンプルな権限モデルであり、エンティティスコープの付与は必要ありません。
各ユニットは完全に自律して動作します。

欠点：

権限の変更だけでなく、組織の再構築が必要です
組織ごとに請求とライセンスが分かれるため、契約構造に影響を与える可能性があります。
共有サービスにはアカウント共有の設定が必要です。
一部の組織横断的なレポートには、カスタムダッシュボードまたはData Plus機能が必要です

個別の組織の次のステップ

このモデルを追求するには、マルチテナンシーを参照し、アカウント担当者に連絡して、共有サービスのワークフロー、ユニットを別々の組織に移行するための移行計画、共有プラットフォームサービスのアカウント共有、および契約と請求への影響について確認してください。

代替の解決策：単一の組織内のRBACパターン

契約上の制約、スケジュール、または組織の抵抗により、ByteFlixが別々の組織に移行できない場合でも、単一の組織内でこのガイドのRBACパターンを使用することで、同様の結果を達成できます。

パターン1：エンティティスコープのアクセス（FGA）

解決する課題：単一の組織内でのビジネスユニットの分離。

仕組み：きめ細かいアクセスを使用して、各ユニットのグループに特定のフリートエンティティへのアクセスのみを付与します。

例：

byteflix-plus-platform-ops byteflix-plus-prod-k8sフリートのみをスコープとするFleet managerロールが付与されます
bbs-platform-ops bbs-prod-k8sフリートのみをスコープとするFleet managerロールが付与されます

結果：ByteFlix+チームはByteFlix+フリートに対してのみ、BBSチームはBBSフリートに対してのみアクションを実行できます。

制限事項：これには、Authentication domain managerがFleet permissions UIを介して初期アクセス付与をセットアップする必要があります。一度確立されると、ユニットリーダーは中央IT部門を関与させることなく、新しいフリートへのアクセスを付与することはできません。

リファレンス：基本パターン。

パターン2：カスタムライフサイクルロール

解決する課題：ライフサイクルの分離。プラットフォームOpsがフリートを形成し、アプリチームがデプロイを行います。

仕組み：Fleetをターゲットとする2つのカスタムエンティティスコープのロールを作成します：

Fleet author、Modifyを保持し、プラットフォームOpsチームに割り当てられます
Fleet deployer、Deployを保持し、アプリチームと請負業者に割り当てられます

その後、パターン1を使用して、特定のフリートエンティティ上のグループに両方のロールが付与されます。

結果：プラットフォームOpsは所有するフリートを形成し、アプリチームはデプロイメントを実行します。どちらもフリートを削除することはできません。

制限事項：カスタムロールを作成するには、Proまたはエンタープライズエディションが必要です。フリートにそれらを付与するには、Fleet permissions UI経由でAuthentication domain managerが必要です。

参考：高度なパターン。

パターン3：グループ管理者の委任

解決する課題：Authentication domain managerなしでの請負業者への委任。

仕組み：ユニットリーダーに、そのユニットのオペレーショングループをスコープとするGroup adminロールを付与します。

ByteFlix+の例：

グループ： byteflix-plus-bu-leads
ロール： Group admin
スコープ：byteflix-plus-platform-opsのメンバーシップを管理でき、 byteflix-plus-app-teams

結果：ユニットリーダーは、中央ITを関与させることなく、またAuthentication domain managerを必要とせずに、グループに請負業者を追加したり、グループから削除したりできます。

制限事項：ユニットリーダーはグループに誰が含まれるかを管理できますが、新しいアクセス付与を作成したり、新しいフリートにグループを割り当てたりすることはできません。新しいフリートが作成された場合でも、中央IT部門がそのアクセス付与を作成する必要があります。

リファレンス：エンタープライズパターン。

統合RBACアーキテクチャー

単一の組織内で3つのパターンすべてを併用する場合、ByteFlixのアーキテクチャーは次のようになります：

Organization: ByteFlix Entertainment

├── ByteFlix+ (Streaming BU):
│   ├── Groups:
│   │   ├── byteflix-plus-bu-leads (Group admin over operational groups)
│   │   ├── byteflix-plus-platform-ops (Fleet author role)
│   │   └── byteflix-plus-app-teams (Fleet deployer role, includes contractors)
│   └── Fleets (entity-scoped to ByteFlix+ groups only):
│       ├── byteflix-plus-prod-k8s
│       └── byteflix-plus-stage-k8s
│
├── BBS (Broadcast BU):
│   ├── Groups:
│   │   ├── bbs-bu-leads (Group admin)
│   │   ├── bbs-platform-ops (Fleet author role)
│   │   └── bbs-app-teams (Fleet deployer role)
│   └── Fleets (entity-scoped to BBS groups only):
│       ├── bbs-prod-k8s
│       └── bbs-stage-k8s
│
└── PixelTV (Cable BU):
    ├── Groups:
    │   ├── pixeltv-bu-leads (Group admin)
    │   ├── pixeltv-platform-ops (Fleet author role)
    │   └── pixeltv-app-teams (Fleet deployer role)
    └── Fleets (entity-scoped to PixelTV groups only):
        ├── pixeltv-prod-k8s
        └── pixeltv-stage-k8s

Custom entity-scoped roles, created once by central IT:
├── Fleet author (Modify)
└── Fleet deployer (Deploy)

RBACのトレードオフ

利点：

組織の再構築は必要ありません。
単一の契約および請求関係
適切に設定された権限付与により、ユニット間の運用上の分離を実現します。

欠点：

中央IT部門による初期設定が必要です。つまり、認証ドメイン管理者の関与が必要になります。
新しいフリートでは依然として中央IT部門がアクセス権限を作成する必要があり、継続的な依存関係となります。
個別の組織よりも複雑な権限モデル
分離は正しいアクセス付与の設定に依存しており、組織の境界によって強制されるものではありません。

このモデルは、誰がフリートを表示できるかではなく、誰がフリートを操作できるかを制御します。

フリートスコープのロールにはRead権限がないため、Fleet Controlで作業するすべてのユーザーには組織スコープの読み取りアクセス権が必要です。ByteFlix+のユーザーは、BBSおよびPixelTVフリートに対してアクションを実行できなくても、それらが存在することを確認できます。

ビジネスユニットが互いのフリートをまったく見ることができないようにする必要がある場合、それを実現できるモデルは個別の組織のみです。

ロール要件

アクション	必要なロール	頻度	メモ
Agent Controlの初期設定	認証ドメインマネージャー	1回	システムIDを作成し、権限を割り当てます。
フリートの作成/更新	組織製品アドミン	継続中	Userグループに自動的に割り当てられます
設定の作成	組織製品アドミン	継続中	Userグループに自動的に割り当てられます
フリートをデプロイする	組織マネージャー、またはフリートごとのフリートマネージャー	継続中	デフォルトのAdminグループに自動的に割り当てられます。または、デプロイを含むフリートスコープのロールを使用します。
フリートとデプロイメントを削除します。	組織マネージャー、またはフリートごとのフリートマネージャー	不定期	設定の削除には組織レベルのスコープが必要です。
設定を承認し、承認ポリシーを設定する	組織マネージャー	継続中	組織スコープのみ；フリートごとにスコープを設定することはできません。
アクセス許可を作成する	認証ドメインマネージャー	新しいフリートごと	ユーザーグループをフリートに割り当てます
グループメンバーシップを管理します。	グループ管理者、委任済み	継続中	完全なドメインマネージャー権限なしでメンバーシップを管理します。パターン3を参照してください。

ロールは加算されるため、複数のロールを持つユーザーはそれらの権限の合計を持ちます。各標準ロールがカバーする内容については、ユーザー管理の概念を参照してください。

既知の問題と回避策

ロールIDを直接クエリできません。

問題：NerdGraphは、名前でロールIDを一覧表示する直接的なクエリを提供していません。

回避策：すでにロールを保持しているグループから読み取ってください：

{
  actor {
    organization {
      authorizationManagement {
        authenticationDomains(id: "YOUR_AUTH_DOMAIN_ID") {
          authenticationDomains {
            groups {
              groups {
                displayName
                roles {
                  roles {
                    roleId
                    displayName
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

フリートGUIDの検索

問題：フリートGUIDは、UIを介して簡単に見つけることができません。

回避策：フリートの詳細ページに移動します。GUIDはURLの/fleets/の後にあります。代わりにフリートをクエリするには、NerdGraph Fleet Controlチュートリアルを参照してください。

クイックリファレンス：NerdGraph IDの検索

組織および認証ドメインID：

{
  actor {
    organization {
      id
      name
      userManagement {
        authenticationDomains {
          authenticationDomains {
            id
            name
          }
        }
      }
    }
  }
}

グループID：

{
  actor {
    organization {
      userManagement {
        authenticationDomains(id: "YOUR_AUTH_DOMAIN_ID") {
          authenticationDomains {
            groups {
              groups {
                id
                displayName
              }
            }
          }
        }
      }
    }
  }
}

アカウントID：New RelicのURLで確認できます。または：

{
  actor {
    accounts {
      id
      name
    }
  }
}

自動化スクリプトテンプレート

複数のフリートやグループを大規模に管理するチーム向けに、New Relic CLIを使用したテンプレートを以下に示します。このテンプレートは、グループを作成し、フリートを作成して、そのフリートへのアクセス権をグループに付与します。

高度なパターンで説明されているように、最初にUIでカスタムロールを作成し、ロールIDをスクリプトに渡します。

bash

$#!/bin/bash
$set -euo pipefail
$
$# Prerequisites:
$#   - New Relic CLI installed and profile configured with a user key
$#   - The Authentication domain manager role, required to create access grants
$#   - A role created in Administration > Access management > Roles, and its ID
$
$AUTH_DOMAIN_ID="YOUR_AUTH_DOMAIN_ID"
$ACCOUNT_ID="YOUR_ACCOUNT_ID"
$ROLE_ID="YOUR_ROLE_ID"
$GROUP_NAME="fleet-architects"
$FLEET_NAME="production-us-east-k8s"
$
$# 1. Create the group. Note the returned group ID.
$echo "Creating group ${GROUP_NAME}..."
$newrelic nerdgraph query 'mutation CreateGroup($authDomainId: ID!, $displayName: String!) {
$  userManagementCreateGroup(createGroupOptions: {
$    authenticationDomainId: $authDomainId
$    displayName: $displayName
$  }) {
$    group { id displayName }
$  }
$}' --variables "{\"authDomainId\": \"${AUTH_DOMAIN_ID}\", \"displayName\": \"${GROUP_NAME}\"}"
$
$# 2. Create the fleet. Note the returned fleet GUID.
$echo "Creating fleet ${FLEET_NAME}..."
$newrelic nerdgraph query 'mutation CreateFleet($name: String!, $scopeId: ID!) {
$  fleetControlCreateFleet(fleetEntity: {
$    name: $name
$    description: "Created by setup script"
$    managedEntityType: KUBERNETESCLUSTER
$    scope: { type: ACCOUNT, id: $scopeId }
$  }) {
$    entity { id name }
$  }
$}' --variables "{\"name\": \"${FLEET_NAME}\", \"scopeId\": \"${ACCOUNT_ID}\"}"
$
$# 3. Grant the group access to the fleet, using the IDs returned above.
$GROUP_ID="GROUP_ID_FROM_STEP_1"
$FLEET_GUID="FLEET_GUID_FROM_STEP_2"
$
$echo "Granting entity-scoped access..."
$newrelic nerdgraph query 'mutation GrantFleetAccess($groupId: ID!, $fleetGuid: ID!, $roleId: ID!) {
$  authorizationManagementGrantAccess(grantAccessOptions: {
$    grantee: { type: GROUP, id: $groupId }
$    entityAccessGrants: {
$      entity: { id: $fleetGuid, type: "fleet" }
$      roleId: $roleId
$    }
$  }) {
$    accessGrants { id }
$  }
$}' --variables "{\"groupId\": \"${GROUP_ID}\", \"fleetGuid\": \"${FLEET_GUID}\", \"roleId\": \"${ROLE_ID}\"}"
$
$echo "Setup complete."

スペースや引用符を含む名前によってリクエストが失敗しないように、手動でクエリ文字列を作成するのではなく、--variablesを使用して値を渡してください。無人でステップを実行するには、各レスポンスをキャプチャし、次の呼び出しの前にそこからIDを読み取ってください。

フリートの更新や削除、デプロイメントの管理など、フリート操作の詳細については、Fleet Control APIおよびCLIをご覧ください。

次のステップ

フリート権限UIおよび設定の承認については、フリートの管理
プログラムによるアクセスのためのFleet Control APIおよびCLI
設定と認証情報がどのように保護されるかについては、Fleet Controlのセキュリティをご覧ください。
グループ、ロール、およびアクセス付与がNew Relic全体でどのように機能するかについては、ユーザー権限およびユーザー管理の概念

この機械翻訳は、参考として提供されています。

どのアプローチが組織に適していますか？

前提条件 .css-21sua1{background:none;border:none;width:0;padding:0;}

ロール要件に関するよくある誤解

Fleet Controlの権限の構成方法

フリートスコープのロールは、読み取りアクセスを置き換えるのではなく、その上に構築されます。

基本パターン：単一フリートの権限（FGA）

UIウォークスルー

フリートの権限が欠落しているか、ロックされた状態で開く場合

NerdGraphの自動化

高度なパターン：ライフサイクル分離のためのカスタムロール

ブループリントの例：カスタムロールの設計

UIウォークスルー

カスタムロールは、新しい権限を自動的に取得しません。

NerdGraphの自動化

エンタープライズパターン：委任されたグループ管理

UIウォークスルー

重要な制限事項

NerdGraphの自動化

複数のビジネスユニットでFleet Controlを委任する

シナリオ

組織構造

課題

推奨される解決策：別々の組織

これが意味すること

利点

共有サービスについてはどうでしょうか？

トレードオフ

個別の組織の次のステップ

代替の解決策：単一の組織内のRBACパターン

パターン1：エンティティスコープのアクセス（FGA）

パターン2：カスタムライフサイクルロール

パターン3：グループ管理者の委任

統合RBACアーキテクチャー

RBACのトレードオフ

このモデルは、誰がフリートを表示できるかではなく、誰がフリートを操作できるかを制御します。

ロール要件

既知の問題と回避策

ロールIDを直接クエリできません。

フリートGUIDの検索

クイックリファレンス：NerdGraph IDの検索

自動化スクリプトテンプレート

次のステップ

前提条件