Utenti e ruoli

NSX utilizza ruoli esistenti e ne introduce alcuni nuovi per supportare la multi-tenancy.

Di seguito sono riportati alcuni dei ruoli utilizzati nel contesto della multi-tenancy:

Ruoli che hanno accesso allo spazio / , che dà loro accesso a tutte le configurazioni in /infra, nonché in /org:
- Amministratore aziendale: l'amministratore del provider è responsabile della preparazione dell'infrastruttura e è un superuser che può accedere alle configurazioni all'interno e all'esterno dei progetti.
- Auditor: gli utenti di questo ruolo hanno accesso in sola lettura alle impostazioni e alla configurazione del sistema, ma hanno accesso completo agli strumenti per la risoluzione dei problemi.
Ruoli introdotti in NSX 4.0.1.1 per la multi-tenancy che hanno accesso solo alla configurazione in /orgs:
- Amministratore dell'organizzazione (anteprima tecnica; non per le distribuzioni di produzione): il ruolo di amministratore dell'organizzazione è attualmente disponibile in modalità anteprima tecnica per gestire i progetti nell'organizzazione. Tuttavia, questo ruolo non ha accesso agli oggetti /infra necessari per creare progetti. Utilizzare il ruolo di amministratore aziendale per la creazione di progetti.
- Amministratore del progetto: l'amministratore del progetto gestisce un progetto e dispone dell'accesso completo alla configurazione all'interno di tale progetto.

Assegnare il ruolo di amministratore del progetto eseguendo la seguente chiamata API:

POST /policy/api/v1/aaa/role-bindings/

Richiesta di esempio:

URL:

POST https://{{nsx-manager-ip}}/policy/api/v1/aaa/role-bindings/

Corpo:

{
    “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
}

È inoltre possibile assegnare i seguenti ruoli esistenti a un progetto specifico fornendo il percorso del progetto:

Amministratore di rete: il ruolo di amministratore di rete, quando assegnato a un percorso di progetto, gestisce le reti e i servizi a livello di progetto.
Operatore di rete: gli utenti con questo ruolo, quando assegnati a un percorso di progetto, hanno accesso in sola lettura alla configurazione di rete a livello di progetto.
Amministratore della sicurezza: il ruolo di amministratore della sicurezza, quando assegnato a un percorso di progetto, gestisce i criteri di sicurezza a livello di progetto.
Operatore della sicurezza: gli utenti con questo ruolo, quando assegnati a un percorso di progetto, dispongono dell'accesso in sola lettura alla configurazione della sicurezza a livello di progetto.

Richiesta di esempio per l'assegnazione di un ruolo a un utente locale per un progetto specifico:

URL:

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

Corpo:

{
    “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
}

Per assicurarsi che all'utente locale venga assegnato solo il ruolo di amministratore del progetto, eliminare il ruolo Revisore.

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

Autenticazione

La multi-tenancy NSX supporta gli utenti configurati in più tipi di origini di identità. Di seguito sono riportati i tipi supportati di origini di identità e i relativi parametri di configurazione:

Utenti locali (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à entità (tramite certificato o token JWT)
I ruoli possono essere assegnati solo utilizzando l'API di identità dell'entità.