Gérer l’accès au contrôle de la flotte

Ce guide fournit des modèles pour configurer le contrôle d’accès basé sur les rôles (RBAC) pour les opérations Fleet Control. Il couvre trois modèles d’implémentation, allant du niveau de base au niveau entreprise, avec des exemples pour l’interface utilisateur et NerdGraph.

Prérequis

Avant de configurer l’un des modèles ci-dessous :

• Utilisateurs de la plateforme complète : chaque autorisation Fleet Control nécessite le type d’utilisateur de la plateforme complète.
• Édition Pro ou Enterprise : requis pour créer les rôles personnalisés, et les groupes personnalisés qu’utilisent ces modèles.
• Rôle de gestionnaire de domaine d’authentification : les utilisateurs disposant du rôle Authentication domain manager peuvent créer des autorisations d’accès, qui attribuent des groupes et des rôles à des parcs spécifiques. Il s’agit d’une exigence de la plateforme New Relic pour toutes les opérations d’octroi d’accès.
• Configuration initiale de Agent Control : nécessite le rôle Authentication domain manager, une fois, pour créer des identités système.
• Créer des flottes et des configurations : nécessite le rôle Organization product admin, qui est automatiquement accordé à toute personne du groupe User par défaut.
• Exécuter des déploiements : nécessite le rôle Organization Manager, qui est automatiquement accordé à toute personne du groupe Admin par défaut. Alternativement, le rôle Fleet manager ou un rôle personnalisé contenant Deploy l’accorde sur des flottes spécifiques, sans portée à l’échelle de l’organisation.

Comment les autorisations du contrôle de la flotte sont organisées

Lorsque vous créez un rôle personnalisé, les autorisations Fleet Control s’affichent sous forme de tableau : une ligne pour la ressource, et des colonnes pour Read, Modify, Delete, et Other. Chaque case à cocher accorde un ensemble d’actions associées plutôt qu’une autorisation individuelle. La ligne que vous obtenez dépend de la portée du rôle.

Les rôles à l’échelle de l’organisation obtiennent la ligne Fleets (all), couvrant chaque flotte de l’organisation :

Les rôles à l’échelle de l’entité ciblant une flotte obtiennent la ligne Fleets (individual), couvrant uniquement les flottes sur lesquelles le rôle est accordé :

L’approbation des configurations et la définition de la politique d’approbation ne sont disponibles que pour les rôles à l’échelle de l’organisation, de sorte que l’autorité d’approbation ne peut pas être limitée à une flotte particulière. Consultez les approbations de configuration pour plus de détails, et déléguer l’autorité d’approbation pour savoir comment l’accorder.

Modèle de base : autorisation de flotte unique (FGA)

Fleet Control prend en charge l’accès granulaire (FGA) via des octrois d’accès limités aux entités. Le rôle Fleet manager intégré peut être limité à des entités de flotte spécifiques, ce qui donne à un groupe un contrôle opérationnel total sur ces flottes, déploiements inclus, sans Organization Manager.

Cela vous permet d’accorder l’accès à une équipe pour gérer une flotte spécifique sans lui donner accès à toutes les flottes de l’organisation.

Présentation de l’interface utilisateur

1. Créer la flotte, si elle n’est pas déjà créée :

   1. Aller à All capabilities > New Relic Control > Fleets
   2. Cliquez Create a fleet
   3. Nommez-le, par exemple production-us-east-fleets
   4. Enregistrer, et noter le GUID de la flotte

2. Créer ou identifier le groupe cible:

   1. Aller à Administration > Access management > Groups
   2. Créer un nouveau groupe, par exemple prod-us-east-fleet-operators, ou en utiliser un existant
   3. Dans la fenêtre modale Create a group, ajoutez des utilisateurs maintenant via la liste déroulante Add users, ou ajoutez-les plus tard en modifiant le groupe
   4. Noter l’ID du groupe

3. Accordez l’accès au niveau de l’entité:

   1. Aller à New Relic Control > Fleets
   2. Sur la ligne du parc, ouvrez le menu kebab et sélectionnez Fleet permissions
   3. Dans la fenêtre modale Fleet permissions, choisissez un groupe, et sélectionnez Fleet manager comme rôle. Ajoutez autant de paires de groupe et de rôle que nécessaire
   4. Cliquez sur Save, ce qui crée un octroi d’accès par paire

Résultat : les membres de prod-us-east-fleet-operators peuvent désormais exécuter des déploiements et gérer les membres pour production-us-east-fleets uniquement. Ils ne peuvent pas modifier d’autres parcs. Ils verront toujours que d’autres parcs existent, car l’accès en lecture provient de leur rôle à l’échelle de l’organisation plutôt que de cet octroi.

Automatisation de 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
    }
  }
}

Comment trouver les ID :

• GUID de la flotte : visible dans l’URL de la page des détails de la flotte, ou effectuez une requête sur les flottes via le tutorielNerdGraph Fleet Control
• ID du groupe : Administration > Access management > Groups, cliquez sur le groupe, l’ID est dans l’URL
• ID de rôle : faites une requête pour l’obtenir à l’aide de la solution de contournement dans les problèmes connus

Modèle avancé : rôles personnalisés pour la séparation du cycle de vie

Créez deux rôles personnalisés à l’échelle de l’entité avec des autorisations Fleet Control différentes, puis accordez chacun à un groupe différent sur les mêmes entités du parc. Fleet manager regroupe Modifier, Supprimer, et déployer, donc lorsque cela représente plus d’autorité qu’un groupe ne devrait en avoir, divisez-le.

Cela vous permet de séparer les personnes qui peuvent modifier la définition et les membres d’un parc de celles qui peuvent exécuter des déploiements, pendant que les deux groupes travaillent sur les mêmes parcs.

Exemple de modèle : conception de rôles personnalisés

Cette section fournit un exemple recommandé de la façon dont vous pouvez concevoir des rôles personnalisés à moindres privilèges pour séparer les autorisations d’architecture de l’exécution du déploiement.

Les deux rôles sont limités à l’entité, et ciblent Fleet:

Aucun des deux rôles ne peut supprimer une flotte, car Delete est une autorisation distincte que vous laissez décochée.

La création de configuration ne fait partie d’aucun des deux rôles, car les configurations dans Fleet Control sont des objets au niveau de l’organisation plutôt que d’appartenir à un parc. Leur création est fournie avec Organization product admin, que le groupe User par défaut possède déjà. En pratique, vos auteurs écrivent des configurations et ces rôles à l’échelle du parc contrôlent ce qui est déployé et où.

Présentation de l’interface utilisateur

1. Créer les rôles personnalisés. Pour chacun d’eux :

   1. Aller à Administration > Access management > Roles
   2. Cliquez Add a role
   3. Pour la portée du rôle, choisissez Single item or entity, puis cliquez Next
   4. Sous Select what you want to configure access to, choisissez Fleet
   5. Nommez le rôle, par exemple Fleet author
   6. Sous Set permissions, développez Fleet Control et sélectionnez ce que le rôle comporte sur la ligne Fleets (individual) : Modify pour le rôle d’auteur, ou Deploy sous Other pour le rôle de déployeur
   7. Enregistrez, puis répétez pour le deuxième rôle

2. Créez des groupes pour chaque rôle:

   1. Créez le groupe fleet-architects pour les auteurs, en ajoutant les utilisateurs pertinents via la liste déroulante Add users dans la modale Create a group, ou plus tard en modifiant le groupe
   2. Créez le groupe fleet-deployment-operators pour les déployeurs, de la même manière

3. Accordez un accès à l’échelle de l’entité pour chaque groupe:

   1. Accédez à New Relic Control > Fleets, ouvrez le menu kebab sur la flotte cible, et sélectionnez Fleet permissions
   2. Ajoutez une paire groupe et rôle : fleet-architects avec Fleet author
   3. Ajoutez une paire groupe et rôle : fleet-deployment-operators avec Fleet deployer
   4. Enregistrez, et les deux autorisations sont créées ensemble

Automatisation de NerdGraph

Les rôles personnalisés sont créés dans l’interface utilisateur. La création de rôles utilise des identifiants d’autorisation internes plutôt que les noms d’autorisation affichés sur les cases à cocher, il n’y a donc pas de chemin d’API pratique pour créer les rôles eux-mêmes.

Une fois que les rôles existent, accordez-les avec la même mutation que le modèle de base, en transmettant l’ID de chaque rôle.

Résultat : les auteurs de parc peuvent façonner les parcs qu’ils possèdent mais ne peuvent pas exécuter de déploiements. Les opérateurs de déploiement peuvent exécuter des déploiements mais ne peuvent pas redéfinir ou supprimer un parc.

Modèle d’entreprise : gestion de groupe déléguée

Utilisez le rôle Group admin avec des attributions à l’échelle du groupe pour déléguer la gestion de l’appartenance au groupe.

Cela vous permet d’autoriser les chefs d’équipe à ajouter et supprimer des membres des groupes de leur équipe sans avoir besoin de tous les privilèges Authentication domain manager.

Présentation de l’interface utilisateur

1. Créer un groupe de gestionnaires:

   1. Aller à Administration > Access management > Groups
   2. Créer un groupe fleet-team-leads
   3. Ajoutez les chefs d’équipe en tant que membres

2. Accorder le rôle d’administrateur de groupe sur les groupes cibles:

   1. Aller à Administration > Access management > Access grants
   2. Cliquez Create new grant
   3. Choisissez une attribution de groupe, qui est le type d’attribution qui cible d’autres groupes
   4. Sélectionner le groupe fleet-team-leads
   5. Rôle : Group admin
   6. Sélectionnez les groupes que les chefs d’équipe devraient pouvoir gérer, par exemple fleet-architects et fleet-deployment-operators
   7. Enregistrer

Résultat : les membres de fleet-team-leads peuvent désormais ajouter et supprimer des utilisateurs de fleet-architects et fleet-deployment-operators sans avoir besoin du rôle Authentication domain manager.

Automatisation de 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
    }
  }
}

Déléguer le contrôle de la flotte avec plusieurs unités commerciales

Cette section décrit un scénario que nous avons observé chez des clients qui ont plusieurs unités commerciales autonomes, et qui ont besoin de déléguer la gestion de Fleet Control. Elle fournit à la fois la solution recommandée, et des approches alternatives utilisant les modèles ci-dessus.

Le scénario

Exemple : ByteFlix Entertainment est une grande entreprise de médias avec plusieurs unités commerciales autonomes opérant sous une seule organisation New Relic :

• ByteFlix+, un service de streaming
• BBS, le système ByteFlix Broadcast, un réseau de diffusion
• PixelTV, un réseau câblé

Structure organisationnelle

Informatique centrale :

• Seules deux ou trois personnes ont les rôles Organization Manager et Authentication domain manager
• Ils gèrent les licences et la gouvernance de New Relic
• Ils ne configurent ou ne créent pas d’entités de monitoring
• Ils constituent un goulot d’étranglement pour les modifications de la gestion des accès

Unités commerciales :

• Chaque unité possède des comptes distincts sous la même organisation New Relic
• Chaque unité gère sa propre observabilité de manière indépendante
• De nombreuses unités font appel à des prestataires pour administrer New Relic Infrastructure

Le défi

ByteFlix souhaite adopter Fleet Control mais rencontre des difficultés :

1. Isolation stricte des unités commerciales requise : les équipes ByteFlix+ ne doivent pas gérer l'infrastructure de BBS ou de PixelTV
2. Délégation aux sous-traitants : les responsables d'unité doivent intégrer des sous-traitants sans impliquer l'informatique centrale
3. Séparation du cycle de vie : les opérations de plateforme doivent définir les flottes et les équipes applicatives doivent déployer, mais les équipes applicatives ne doivent pas pouvoir supprimer ou redéfinir les flottes
4. Aucune attribution d’administration étendue : le service informatique central n’accordera pas Authentication domain manager aux équipes de l’unité pour des raisons de sécurité

Solution recommandée : des organisations distinctes

En fonction de la structure organisationnelle de ByteFlix, le multi-tenant est la solution idéale.

Ce que cela signifie

Au lieu d’une seule organisation avec plusieurs comptes, ByteFlix crée trois organisations New Relic distinctes :

• Organisation ByteFlix+, avec ses propres comptes
• Organisation BBS, avec ses propres comptes
• Organisation PixelTV, avec ses propres comptes

Chaque unité commerciale devient sa propre organisation New Relic isolée.

Avantages

1. Isolation complète des unités commerciales : les fonctionnalités à l’échelle de l’organisation, y compris Fleet Control, ne voient que les données au sein de l’organisation de cette unité
2. Aucune visibilité inter-unités : les utilisateurs de ByteFlix+ ne peuvent pas voir les entités BBS ou PixelTV, ce qui est garanti par les limites organisationnelles
3. Administration autonome : chaque unité possède ses propres gestionnaires de domaine d’authentification et gestionnaires d’organisation sans affecter les autres
4. Délégation aux prestataires : chaque unité peut accorder un accès prestataire sans impliquer le service informatique central, ou les autres unités
5. Autorisations plus simples : aucune attribution à l’échelle de l’entité ni rôle personnalisé n’est nécessaire pour appliquer l’isolation

Qu’en est-il des services partagés ?

Le partage de compte New Relic permet aux comptes de franchir les limites organisationnelles. Si ByteFlix dispose de services de plateforme partagés, tels que le logging centralisé ou une infrastructure partagée, qui nécessitent une visibilité à travers les unités, ces comptes peuvent être partagés dans plusieurs organisations.

Par exemple, le service informatique central gère une organisation d’observabilité partagée avec les comptes de plateforme partagés, et les organisations ByteFlix+, BBS et PixelTV ont chacune un accès en lecture à ces comptes via le partage de compte.

Compromis

Avantages :

• Modèle d’isolation le plus fort, appliqué par les limites de l’organisation
• Modèle d'autorisations le plus simple, sans aucune attribution au niveau de l'entité requise
• Chaque unité fonctionne de manière totalement autonome

Inconvénients :

• Nécessite une restructuration organisationnelle, et pas seulement des modifications d’autorisations
• Facturation et licences séparées par organisation, ce qui peut affecter la structure du contrat
• Les services partagés nécessitent la configuration du partage de compte
• Certains rapports inter-organisations nécessitent des dashboards personnalisés ou des fonctionnalités Data Plus

Prochaines étapes pour les organisations distinctes

Pour poursuivre ce modèle, consultez la section multi-locataire, puis contactez votre représentant de compte pour travailler sur les workflows de services partagés, un plan de migration pour déplacer des unités vers des organisations distinctes, le partage de compte pour tous les services de plateforme partagés, ainsi que les implications en matière de contrat et de facturation.

Solution alternative : modèles RBAC au sein d’une seule organisation

Si ByteFlix ne peut pas passer à des organisations distinctes, en raison de contraintes contractuelles, de délais, ou de résistance organisationnelle, ils peuvent obtenir des résultats similaires en utilisant les modèles RBAC de ce guide au sein d'une seule organisation.

Modèle 1 : accès à l’échelle de l’entité (FGA)

Ce que cela résout : la séparation des unités opérationnelles au sein d’une seule organisation.

Fonctionnement : utilisez un accès granulaire pour accorder aux groupes de chaque unité l’accès uniquement à leurs entités de flotte spécifiques.

Exemple:

• byteflix-plus-platform-ops rôle Fleet manager accordé, limité au parc byteflix-plus-prod-k8s uniquement
• bbs-platform-ops rôle Fleet manager accordé, limité au parc bbs-prod-k8s uniquement

Résultat : les équipes ByteFlix+ ne peuvent agir que sur les flottes ByteFlix+, et les équipes BBS uniquement sur les flottes BBS.

Limitation : cela nécessite que Authentication domain manager configure les autorisations d'accès initiales via l'interface utilisateur Fleet permissions. Une fois en place, les responsables d’unité ne peuvent pas accorder d’accès à de nouveaux parcs sans impliquer le service informatique central.

Référence : modèle de base.

Modèle 2 : rôles de cycle de vie personnalisés

Ce que cela résout : la séparation du cycle de vie, avec les opérations de plateforme qui façonnent les parcs et les équipes d’application chargées de déployer.

Fonctionnement : créez deux rôles personnalisés à l’échelle de l’entité ciblant Fleet:

• Auteur de flotte, portant Modify, assigné aux équipes des opérations de la plateforme
• Déployeur de flotte, portant Deploy, assigné aux équipes d’application et aux prestataires

Les deux rôles sont ensuite accordés à leurs groupes sur des entités de flotte spécifiques en utilisant le Modèle 1.

Résultat : les opérations de plateforme configurent les flottes qu’elles possèdent, les équipes applicatives exécutent les déploiements, et aucune des deux ne peut supprimer une flotte.

Limitation : la création de rôles personnalisés nécessite l’édition Pro ou l’édition Enterprise. Leur attribution sur des flottes nécessite Authentication domain manager, via l’interface utilisateur Fleet permissions.

Référence : modèle avancé.

Modèle 3 : délégation d’administration de groupe

Ce que cela résout : délégation aux prestataires sans Authentication domain manager.

Fonctionnement : accordez aux responsables d’unité le rôle Group admin limité aux groupes opérationnels de leur unité.

Exemple pour ByteFlix+ :

• Groupe : byteflix-plus-bu-leads
• Rôle : Group admin
• Périmètre : peut gérer les membres de byteflix-plus-platform-ops, et byteflix-plus-app-teams

Résultat : les responsables d’unité peuvent ajouter et retirer des prestataires des groupes sans impliquer le service informatique central et sans avoir besoin de Authentication domain manager.

Limitation : les responsables d’unité peuvent gérer qui fait partie d’un groupe, mais ne peuvent pas créer de nouvelles autorisations d’accès ni attribuer des groupes à de nouveaux parcs. Lorsqu’un nouveau parc est créé, le service informatique central doit toujours créer l’autorisation d’accès correspondante.

Référence : modèle d’entreprise.

Architecture RBAC combinée

En utilisant les trois modèles ensemble au sein d’une seule organisation, l’architecture de ByteFlix ressemble à ceci :

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)

Compromis RBAC

Avantages :

• Aucune restructuration organisationnelle requise
• Contrat unique et relation de facturation
• Permet une séparation opérationnelle entre les unités avec des attributions correctement configurées

Inconvénients :

• Nécessite une configuration initiale par l’équipe informatique centrale, ce qui implique l’intervention du gestionnaire du domaine d’authentification
• Les nouvelles flottes nécessitent toujours que l’équipe informatique centrale crée des autorisations d’accès, une dépendance continue
• Un modèle de permissions plus complexe que des organisations distinctes
• La séparation dépend d’une configuration correcte des autorisations d’accès, et n’est pas imposée par les limites organisationnelles

Exigences de rôle

Les rôles sont cumulatifs, un utilisateur qui en possède plusieurs dispose donc de la somme de leurs permissions. Pour savoir ce que couvre chaque rôle standard, consultez les concepts de gestion des utilisateurs.

Problèmes connus et solutions de contournement

Impossible d’interroger directement les ID de rôle

Problème : NerdGraph ne fournit pas de requête directe pour lister les ID de rôle par nom.

Solution de contournement : lisez-les à partir des groupes qui possèdent déjà le rôle :

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

Trouver les GUID de flotte

Problème : les GUID de flotte ne sont pas facilement repérables via l’interface utilisateur.

Solution de contournement : accédez à la page des détails de la flotte, où le GUID se trouve dans l’URL après /fleets/. Pour effectuer une requête sur les flottes à la place, consultez le tutorielNerdGraph Fleet Control .

Référence rapide : trouver les ID NerdGraph

ID d’organisation et de domaine d’authentification :

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

ID de groupe :

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

ID de compte : visible dans l'URL New Relic, ou :

{
  actor {
    accounts {
      id
      name
    }
  }
}

Modèle de script d’automatisation

Pour les équipes gérant plusieurs flottes et groupes à grande échelle, voici un modèle utilisant la CLI New Relic. Cela crée un groupe, crée une flotte, et accorde au groupe l’accès à cette flotte.

Créez d’abord les rôles personnalisés dans l’interface utilisateur, comme décrit dans le modèle avancé, et passez l’ID du rôle dans le script.

$
#!/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."

Transmettez les valeurs avec --variables plutôt que de créer des chaînes de requête à la main, afin que les noms contenant des espaces, ou des guillemets ne rompent pas la requête. Pour exécuter les étapes sans surveillance, capturez chaque réponse, et lisez-en les ID avant le prochain appel.

Pour un ensemble plus complet d’opérations de flotte, y compris la mise à jour et la suppression de flottes et la gestion des déploiements, voir API et CLIFleet Control .

Et ensuite ?

• Gérer les flottes pour l’interface utilisateur des autorisations de flotte et les approbations de configuration
• API et CLI du contrôle de la flotte pour l’accès programmatique
• Sécurité du contrôle de la flotte pour savoir comment les configurations et les identifiants sont protégés
• Autorisations de l’utilisateur et concepts de gestion des utilisateurs pour savoir comment les groupes, les rôles, et les octrois d’accès fonctionnent dans tout New Relic