Rôles et autorisations

Fundamentum utilise un contrôle d'accès basé sur les rôles : un rôle est un ensemble d'autorisations, et vous l'accordez à une personne ou à un compte de service sur un projet, une licence ou un site précis. Les personnes obtiennent des rôles au moyen d'invitations par e-mail ; les machines les obtiennent au moyen de comptes de service.

Avant de commencer

• Vous détenez un rôle qui peut gérer les utilisateurs là où vous accordez l'accès : project_manager sur le projet, license_manager sur une licence ou container_admin sur l'organisation.
• Vous avez accès à Connect, et à la CLI fun connectée ou à un jeton pour la Public API. Consultez Authentification.
• Vous connaissez votre <project-id>.

Fonctionnement

User or service account ── holds ──▶ Role ── granted on ──▶ one item: a project, a license, a site
                                      │
                                   bundles
                                      ▼
                     Permission = action + container + scope

• Un conteneur (container) est un type d'élément auquel s'appliquent les autorisations : organisation, projet, appareil, licence, site, Insight, fonctions, et d'autres. Les conteneurs sont imbriqués ; un rôle accordé sur un projet s'étend donc aux licences et aux sites qui s'y trouvent.
• Une action est ce qui peut être fait sur un conteneur : list, show, store, update, delete, manage-users, et pour les fonctions invoke, upload et monitor.
• La portée (scope) est All (tous les éléments de ce type) ou Own (uniquement l'élément sur lequel le rôle a été accordé).
• Un rôle n'est jamais accordé dans l'abstrait : c'est « gestionnaire de projet sur ce projet ».

Une seule correspondance suffit : un gestionnaire de licence et un gestionnaire de projet peuvent tous deux gérer les utilisateurs d'un même site, chacun depuis son propre niveau.

1. Choisir un rôle

Ces rôles sont fournis avec chaque installation :

Les ID de rôle dépendent de l'environnement. Pour les trouver, listez les conteneurs, puis les rôles de celui sur lequel vous accordez l'accès (project, license ou location pour les sites) :

fun api v2 authorization-containers list-containers --project-id <project-id>
fun api v2 authorization-container-roles list-container-roles --project-id <project-id> --container-id <container-id>

2. Inviter un utilisateur

Dans Connect, ouvrez Users, sélectionnez New User, puis choisissez le rôle, le nom, l'e-mail et un message facultatif. Vous pouvez aussi utiliser l'API. Pour un projet, container_item_id est l'ID du projet :

fun api v2 projects-users-invitations create-invitation --project-id <project-id> --body '{
  "name": "Alex Martin",
  "email": "alex.martin@example.com",
  "role_id": <role-id>,
  "container_item_id": <project-id>,
  "options": {},
  "redirect_url": "https://hub.example.com/",
  "custom_message": "Welcome to the fleet project."
}'

Une invitation est en attente (pending) jusqu'à ce que l'utilisateur la termine, puis terminée (completed) une fois le rôle attribué. Elle se termine immédiatement lorsque l'utilisateur possède déjà un compte fonctionnel, détient déjà ce rôle sur cet élément, ou s'est invité lui-même. Une invitation porte un seul rôle : invitez de nouveau la même personne pour chaque rôle supplémentaire. Pour les licences et les sites, consultez Licences.

3. Examiner et révoquer les accès

fun api v2 projects-users-invitations list-invitations --project-id <project-id>
fun api v2 projects-users-invitations delete-invitation --project-id <project-id> --invitation-id <invitation-id>

La suppression d'une invitation terminée retire le rôle. Une invitation en attente peut encore être modifiée avec update-invitation.

4. Créer un compte de service pour l'automatisation

Un compte de service est une identité non humaine destinée à vos scripts, à vos pipelines CI et à vos intégrations. Il appartient à un seul projet.

# Create it
fun api v2 service-accounts create-service-account --project-id <project-id> --body '{"name": "ci-deployer"}'

# Grant it a project role
fun api v2 service-accounts create-service-account-role --project-id <project-id> \
  --service-account-id <service-account-id> --body '{"role_id": <role-id>}'

# Issue a token
fun api v2 service-accounts create-service-account-token --project-id <project-id> \
  --service-account-id <service-account-id> --body '{"name": "pipeline"}'

Le jeton se trouve dans accessToken, et il n'est affiché qu'une seule fois : conservez-le dans votre gestionnaire de secrets. Utilisez-le sous la forme Authorization: Bearer $TOKEN, ou avec la CLI au moyen de ses variables d'environnement (consultez La CLI fun). Supprimez un jeton compromis ou inutilisé avec delete-service-account-token.

Accordez le rôle le plus restreint qui permet de faire le travail, par exemple functions_invoker pour un pipeline qui ne fait qu'exécuter des fonctions.

5. Définir vos propres conteneurs (avancé)

Un projet peut sécuriser ses propres ressources en définissant des conteneurs. Un nouveau conteneur reçoit automatiquement list, show, store, update et delete. Ajoutez vous-même les autres actions, comme manage-users :

fun api v2 authorization-containers create-container --project-id <project-id> \
  --body '{"slug": "project-<project-id>-parking-gates", "name": "Parking gates"}'
fun api v2 authorization-container-actions create-container-action --project-id <project-id> --container-id <container-id> \
  --body '{"name": "open", "label": "Open gate", "short_label": "Open gate (All)", "scope": "global"}'

Accordez ensuite les actions à un rôle dans Connect. Vos applications les vérifient au moyen de fun api v2 users introspect-user, qui renvoie l'appelant avec ses rôles et ses autorisations.

Prochaines étapes

• Référence de l'API dans Swagger UI : Projects: Users/Invitations, Service Accounts, Authorization: Containers
• Licences : servir vos propres clients
• Alertes : notifiez les utilisateurs ou toutes les personnes détenant un rôle.
• Authentification