NSX utilise des rôles existants et en ajoute de nouveaux pour prendre en charge l'architecture mutualisée.

Voici quelques-uns des rôles utilisés dans le contexte de l'architecture mutualisée :

  • Rôles ayant accès à l'espace / qui leur donne ainsi accès à toutes les configurations sous /infra ainsi qu'à la valeur /org :
    • Administrateur d'entreprise : l'administrateur fournisseur est responsable de la préparation de l'infrastructure et est un super utilisateur qui peut accéder aux configurations dans les projets et à l'extérieur de ceux-ci.
    • Auditeur : les utilisateurs détenant ce rôle disposent d'un accès en lecture seule aux paramètres système et à la configuration, mais disposent d'un accès complet aux outils de dépannage.
  • Rôles ajoutés dans NSX 4.0.1.1 pour l'architecture mutualisée qui n'a accès qu'à la configuration sous /orgs :
    • Administrateur d'organisation (tech preview ; pas pour les déploiements de production) : le rôle d'administrateur d'organisation est actuellement disponible en mode tech preview pour gérer les projets de l'organisation. Toutefois, ce rôle n'a pas accès aux objets /infra requis pour créer des projets. Utilisez le rôle d'administrateur d'entreprise pour la création de projet.
    • Administrateur de projet : gère un projet et dispose d'un accès complet à la configuration de ce projet.
Attribuez le rôle d'administrateur de projet en effectuant l'appel d'API suivant : 
POST /policy/api/v1/aaa/role-bindings/
Exemple de demande :
URL : 
POST https://{{nsx-manager-ip}}/policy/api/v1/aaa/role-bindings/
Corps : 
{
    “name”: “[email protected]”,
    “type”: “remote_user”,
    “roles_for_paths”: [
        {
            “path”: “/orgs/default/projects/project-1”,
            “roles”: [
                {
                    “role”: “project_admin”
                }
            ]
        }
    ],
    “resource_type”: “RoleBinding”,
    “identity_source_type”: “LDAP”,
    “read_roles_for_paths”: true
}
Vous pouvez également attribuer les rôles existants suivants à un projet spécifique en fournissant le chemin du projet :
  • Administrateur réseau : lorsqu'il est attribué à un chemin de projet, le rôle d'administrateur réseau gère les réseaux et les services au niveau de ce projet.
  • Opérateur de réseau : lorsqu'ils sont affectés à un chemin de projet, les utilisateurs avec ce rôle disposent d'un accès en lecture seule à la configuration de la mise en réseau au niveau de ce projet.
  • Administrateur de sécurité : lorsqu'il est attribué à un chemin de projet, le rôle d'administrateur de sécurité gère les stratégies de sécurité au niveau de ce projet.
  • Opérateur de sécurité : lorsqu'ils sont affectés à un chemin de projet, les utilisateurs avec ce rôle disposent d'un accès en lecture seule à la configuration de la sécurité au niveau de ce projet.
Exemple de demande d'attribution d'un rôle vers un utilisateur local pour un projet spécifique :
URL : 
POST https://{{nsx-manager-ip}}/policy/api/v1/aaa/role-bindings/<RoleBinding ID>
Corps : 
{
    “name”: “[email protected]”,
    “type”: “local_user”,
    “roles_for_paths”: [
        {
            “path”: “/orgs/default/projects/project-1”,
            “roles”: [
                {
                    “role”: “project_admin”
                }
            ]
        }
    ],
    “resource_type”: “RoleBinding”,
    “read_roles_for_paths”: true
}

Pour vous assurer que seul le rôle Administrateur de projet est attribué à l'utilisateur local, supprimez le rôle Auditeur.

DELETE https://{{nsx}}/policy/api/v1/aaa/role-bindings/<RoleBinding ID>

Authentification

L'architecture mutualisée de NSX prend en charge les utilisateurs configurés sur plusieurs types de sources d'identité. Voici les types de sources d'identité pris en charge et leurs paramètres de configuration :
  • Utilisateurs locaux (admin, audit, guestuser1, guestuser2)
    “type”: “local_user”,
  • vIDM (VMware Identity Manager)
    “type”: “remote_user”,
“identity_source_type”: “VIDM”,
  • LDAP (Lightweight Directory Access Protocol)
    “type”: “remote_user”,
“identity_source_type”: “LDAP”,
  • Identité de principal (via un certificat ou un jeton JWT)

    Les rôles peuvent uniquement être attribués à l'aide de l'API d'identité de principal.