Gérer les rôles, les comptes, les utilisateurs et les domaines¶

Rôles, Comptes, Utilisateurs et Domaines¶

Rôles¶

Un rôle représente un ensemble de fonctions autorisées. Tous les comptes CloudStack ont un rôle qui leur est attaché et qui applique des règles qui lui autorisent ou qui lui refusent une requête d’API. Typiquement, il existe 4 rôles par défaut : admin root, admin de ressources, admin de domaine et utilisateur.

Comptes¶

Un compte représente généralement un client du fournisseur de service ou un département dans une grande organisation. Plusieurs utilisateurs peuvent exister dans un compte.

Domaines¶

Les comptes sont regroupés par domaines. Les domaines contiennent généralement plusieurs comptes qui ont une certaine relation logique entre eux et un ensemble d’administrateurs délégués avec une certaine autorité sur le domaine et ses sous-domaines. Par exemple, un fournisseur de services avec plusieurs revendeurs pourrait créer un domaine pour chaque revendeur.

Pour chaque compte créé, le Cloud crée trois types de comptes différents: administrateur root, administrateur de domaine et utilisateur.

Utilisateurs¶

Les utilisateurs sont comme des alias dans le compte. Les utilisateurs qui sont dans le même compte ne sont pas isolés les uns des autres mais sont isolés des utilisateurs des autres comptes. La plupart des installations n’ont aucune notion des utilisateurs; elles ont seulement un utilisateur par compte. Un même utilisateur ne peut pas appartenir à plusieurs comptes.

Le nom d’utilisateur est unique dans un domaine. Le même nom d’utilisateur peut exister dans d’autres domaines ou sous-domaines. Un nom de domaine peut être réutilisé seulement si le chemin complet est unique. Par exemple, vous pouvez créer root/d1, ainsi que root/exemple/d1 et root/ventes/d1.

Les administrateurs sont des comptes disposants de droits spéciaux dans le système. Il peut y avoir plusieurs administrateurs dans le système. Les administrateurs peuvent créer ou supprimer d’autres administrateurs et changer le mot de passe de n’importe quel utilisateur du système.

Administrateurs de domaine¶

Les administrateurs de domaine peuvent exécuter des opérations administratives pour les utilisateurs appartenant à leur domaine. Les administrateurs de domaine n’ont pas de visibilité sur les serveurs physiques ou sur les autres domaines.

Administrateur root¶

Les administrateurs racines ont un accès complet au système, incluant la gestion des modèles, les offres de service, les administrateurs de clientèles et les domaines.

Propriétaire d’une ressource¶

Les ressources appartiennent à un compte, elles n’appartiennent pas à un utilisateur individuel de ce compte. Par exemple, la facturation, les limites de ressources, etc. sont calculées pour un compte, elles ne le sont pas par utilisateurs. Un utilisateur peut opérer sur n’importe quelle ressource de son compte pour peu que le compte fournissant l’utilisateur dispose des privilèges pour cette opération. Les privilèges sont déterminés par le rôle. Un administrateur peut changer le propriétaire de n’importe quelle machine virtuelle d’un compte vers un autre compte en utilisant l’API assignVirtualMachine. Un administrateur de domaine ou de sous-domaine peut faire de même pour les machines virtuelles de son domaine d’un compte à un autre compte de son domaine ou de n’importe lequel de ses sous-domaines.

Utiliser les rôles dynamiques¶

En complément des quatre rôles par défaut, la fonctionnalité de vérification d’API basée sur les rôles dynamiques autorise les administrateurs à créer de nouveaux rôles avec des permissions personnalisées. Les règles d’autorisations/refus peuvent être configurées dynamiquement durant le fonctionnement sans devoir redémarrer le(s) serveur(s) de gestion.

Pour une compatibilité ascendante, tous les rôles sont rattachés à un des quatre types de rôle : admin, admin de ressource, admin de domaine, et utilisateur. Un nouveau rôle peut être créé en utilisant les onglets rôles dans l’interface en spécifiant un nom, un type de rôle et optionnellement une description.

Les règles spécifiques d’un rôle peuvent être configurés par l’onglet règles dans la page de détails d’un rôle spécifique. Une règle est soit un nom d’API ou un chaîne de caractères jockers qui sont une autorisation ou un refus et optionnellement une description.

Quand un utilisateur effectue une requête d’API, le backend vérifie si l’API demandée apparaît dans les règles configurées (dans l’ordre dont les règles ont été configurées) pour le rôle du compte utilisateur appelant. Il va parcourir toutes les règles et autorisera la requête d’API si l’API correspond à une règle d’autorisation, ou la refusera si elle correspond à une règle de refus. Ensuite, si la requête d’API échoue dans la correspondance avec une règle configurée, il l’autorisera si l’API par défaut autorise ce type de rôle utilisateur et finalement refusera la requête d’API s’il échoue à l’autoriser/refuser explicitement par les règles de permissions des rôles ou par l’autorisation par défaut de l’API. Note : pour éviter à l’administrateur d’être verrouillé par le système, tous les comptes d’administrateur racine sont autorisés pour toutes les APIs.

La fonctionnalité de rôles dynamiques est activée par défaut seulement pour les nouvelles installations de CloudStack depuis la version 4.9.x.

Après une montée de version, les déploiements déjà existant peuvent être migrés pour mettre en oeuvre cette fonctionnalité en lançant l’outil de migration en tant qu’administrateur CloudStack. L’outil de migration se situe sous /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py.

Durant la migration, cet outil active un drapeau interne dans la base de données, copie les règles statiques basées sur les rôles depuis le fichier commands.properties fournit (typiquement sous /etc/cloudstack/management/commands.properties) vers la base de données et renomme le fichier commands.properties (typiquement sous /etc/cloudstack/management/commands.properties.deprecated). Le processus de migration ne nécessite pas un redémarrage du ou des serveurs de gestion.

Utilisation : migrate-dynamicroles.py [options] [-h pour l’aide]

Options :

`-b DB`	Le nom de la base de données, par défaut : cloud
`-u USER`	Nom d’utilisateur : un utilisateur MySQL avec les privilèges sur la base de données cloud, par défaut : cloud
`-p PASSWORD`	Mot du passe de l’utilisateur MySQL disposant des privilèges sur la base de données cloud
`-H HOST`	Nom d’hôte ou adresse IP du serveur Mysql
`-P PORT`	Port du serveur Mysql, par défaut : 3306
`-f FILE`	Le fichier commands.properties, par défaut : /etc/cloudstack/management/commands.properties
`-d`	Cet outil va effectuer des tests et des opérations de debuggage.

Exemple :

sudo python /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py -u cloud -p cloud -h localhost -p 3006 -f /etc/cloudstack/management/commands.properties

Si vous avez plusieurs serveurs de gestion, supprimer ou renommer le fichier commands.properties sur tous les serveurs de gestion, typiquement sous /etc/cloudstack/management, après avoir lancé l’outil de migration sur le premier serveur de gestion.

Dédier des ressources à des comptes et des domaines¶

L’administrateur root peut dédier des ressources à un domaine spécifique ou à un compte qui nécessite une infrastructure privée pour plus de sécurité ou des garanties de performances. Une zone, un pod, un cluster ou un hôte peut être réservé par l’administrateur root pour un domaine ou un compte spécifique. Seuls les utilisateurs dans ce domaine ou ses sous-domaines peut utiliser cette infrastructure. Par exemple, seuls les utilisateurs dans un domaine donné peut créer des invités dans la zone dédiées à ce domaine.

Ils existes de nombreux types d’attribution possibles :

Attribution explicite. Une zone, un pod, un cluster ou un hôte sont dédiés à un compte ou un domaine par l’administrateur racine durant le déploiement initial et la configuration.
Attribution stricte implicite. Un hôte ne sera pas partagé pour différents comptes. Par exemple, une attribution stricte implicite est utile pour le déploiement de certains types d’applications, comme les applications de bureaux, où aucun hôte ne peut être partagé entre des comptes différents sans violer les termes de licences du logiciel de bureau.
Attribution implicite préférée. La VM sera déployée si possible dans l’infrastructure dédiée. Sinon, la VM peut être déployée dans l’infrastructure partagée.

Comment dédier une zone, un cluster, un pod ou un hôte à un compte ou à un domaine¶

Pour l’attribution explicite : lors du déploiement d’une nouvelle zone, d’un pod, d’un cluster ou d’un hôte, l’administrateur root peut cliquer sur la case à cocher Dedié, et choisir alors un domaine ou un compte propriétaire de la ressource.

Pour explicitement dédié une zone, un pod, un cluster ou un hôte déjà existant : se connecter en tant qu’administrateur root, trouver la ressource dans l’interface et cliquer sur le bouton Dédier.

Pour l’attribution implicite : L’administrateur créer une offre de service !compute! et dans le champ Planification de déploiement, choisit ImplicitDedicationPlanner. Alors, ans le mode Plannification, l’administraeur spécifie soit Strict, soit Préféré, en fonction de s’il est possible d’autoriser l’utilisation de ressources partagées lorsque les ressources dédiées ne sont pas disponibles. Même si un utilisateur créé une VM basée sur cette offre de service, elle est allouée sur un de ses hôtes dédiés.

Comment utiliser les Hôtes Dédiés¶

Pour utiliser un hôte dédié explicitement, utiliser le type de groupe d’affinité Explicitement-dédié (voir “Groupes d’affinité”). Par exemple, lorsque une nouvelle VM est créée, un utilisateur final peut choisir de la placer dans son infrastructure dédiée. Cette opération fonctionnera seulement si une partie de son infrastructure a déjà été assignée comme dédiée au compte de l’utilisateur ou au domaine.

Comportement des hôtes, clusters, pods et zones dédiés¶

L’administrateur peut migrer à chaud des machines virtuelles depuis ses hôtes dédiés, s’il le désire, même si la destination est un hôte réservé pour un compte/domaine différent ou si un hôte est partagé (non dédié à un compte ou un domaine particulier). CloudStack va générer une alerte, mais l’opération sera permise.

Les hôtes dédiés peuvent être utilisés en conjonction avec les tags d’hôtes. Si à la fois un tag d’hôtes et une réservation sont demandées, la machine virtuelle sera placée seulement sur un hôte qui réponds aux deux requêtes. S’il n’y a pas de ressources dédiées disponible pour cet utilisateur qui n’aurait également le tag d’hôte demandé par l’utilisateur, alors la machine ne sera pas déployée.

Si vous supprimez un compte ou un domaine, tous les hôtes, les clusters, les pods, et les zones qui lui ont été dédiées sont libérées. Ils seront dorénavant disponibles pour être partagés par n’importe quel compte ou domaine, ou l’administrateur peut choisir de les dédier à nouveau à un autre compte ou un autre domaine.

Les machines virtuelles systèmes et les routeurs virtuels affecte le comportement de la réservation d’hôte. Les machines virtuelles et les routeurs virtuels appartiennent au compte système CloudStack et peuvent être déployé sur n’importe quel hôte. Ils ne respecte pas les réservations explicites. La présence de VM systèmes et de routeurs virtuels sur un hôte rendent la réservation explicite stricte inappropriée. L’hôte ne peut pas servir pour la réservation implicite puisque l’hôte a déjà des VMs d’un compte spécifique (le compte système par défaut). Toutefois, un hôte avec des VMs systèmes ou des routeurs virtuels peut être utilisé pour la réservation implicite préférée.

Utiliser un serveur LDAP pour l’authentification des utilisateurs¶

Vous pouvez utiliser un serveur LDAP externe comme Microsoft Active Directory ou ApacheDS pour authentifier les utilisateurs CloudStack. CloudStack cherchera dans l’arbre de l’annuaire LDAP externe depuis un répertoire de base spécifié et obtiendra les informations de l’utilisateur comme son nom, son prénom, son email et son nom d’utilisateur.

Pour l’authentification, le nom d’utilisateur et le mot de passe saisis par l’utilisateur sont utilisés. CloudStack effectue une recherche pour un utilisateur avec le nom fourni. S’il existe, il effectue une requête d’authentification avec le DN et le mot de passe.

Pour paramétrer l’authentification LDAP dans CloudStack, appeler la commande d’API CloudStack ``addLdapConfiguration``et fournir un nom de machine ou une adresse IP et le port d’écoute du serveur LDAP. Vous pouvez bien entendu configurer plusieurs serveurs. Ces derniers sont considérés comme des réplicats. Si un serveur tombe en panne, le suivant sera utilisé.

Les options de configuration globale suivantes devraient également être configurée (les valeurs par défaut s’applique à openldap)

ldap.basedn: Positionne le basedn pour LDAP. Ex: OU=APAC,DC=company,DC=com
ldap.bind.principal, ldap.bind.password: DN et mot de passe pour l’utilisateur qui dispose des droits pour lister tous les utilisateurs dans la basedn fournie ci-dessus. Ex: CN=Administrator, OU=APAC, DC=company, DC=com
ldap.user.object: type d’objet définissant les utilisateurs au sein de LDAP. La valeur par défaut est user pour AD et inetorgperson pour openldap.
ldap.email.attribute: attributs email au sein de LDAP pour un utilisateur. La valeur par défaut pour AD et pour openldap est mail.
ldap.firstname.attribute: attribut prénom au sein de LDAP pour un utilisateur. La valeur par défaut pour AD et openldap est givenname.
ldap.lastname.attribute: attribut nom de famille au sein de LDAP pour un utilisateur. La valeur par défaut pour AD et openldap est sn.
ldap.username.attribute: attribut nom d’utilisateur pour un utilisateur au sein de LDAP. La valeur par défaut est SAMAccountName pour AD et uid pour openldap.

Restreindre les utilisateurs LDAP à un groupe :¶

ldap.search.group.principle: ceci est optionnel et si positionné seuls les utilisateurs de ce groupe sont listés.

LDAP SSL :¶

Si le serveur LDAP nécessite SSL, vous devez activer les configurations ci-dessous. Avant d’activer SSL pour LDAP, vous devez obtenir le certificat utilisé par le serveur LDAP et l’ajouter à votre magasin de confiance. Vous devez connaître le chemin d’accès au magasin et le mot de passe.

ldap.truststore : chemin d’accès au magasin de clefs
ldap.truststore.password : mot de passe du magasin de clefs

Groupes LDAP :¶

ldap.group.object: type d’objet pour un groupe au sein de LDAP. La valeur par défaut pour AD est group pour AD et groupOfUniqueNames pour openldap.
ldap.group.user.uniquemember: attributs pour les membres d’un groupe. La valeur par défaut est member pour AD et uniquemember pour openldap.

Une fois configuré, sur la page Ajout de compte, vous verrez un bouton “Ajouter un compte LDAP” qui ouvre une boîte de dialogue et les utilisateurs sélectionnés peuvent être importés.

Vous pouvez également utiliser les commandes d’API : listLdapUsers, ldapCreateAccount et importLdapUsers.

Une fois que LDAP est activé, les utilisateurs ne seront plus autorisés à changer leurs mots de passe directement depuis depuis CloudStack.

Utiliser un fournisseur d’identité SAML 2.0 pour l’authentification des utilisateurs¶

Vous pouvez utiliser un fournisseur d’identité SAML 2.0 avec CloudStack pour l’authentification utilisateur. Cela nécessitera d’activer le plugin du fournisseur de service SAML 2.0. Pour cela, activer le plugin SAML en configuration saml2.enabled à true et redémarrer le serveur de gestion.

Depuis la version 4.5.2, le plugin SAML utilise un workflow d’autorisation dans lequel les utilisateurs devrait être autorisés par un administrateur à utiliser l’API authorizeSamlSso. Auparavant, ces utilisateurs pouvaient utiliser le Single Sign On via un IdP spécifique. Ceci peut être fait en cochant la case d’activation SAML Single Sign On et en sélectionnant un IdP lors de l’ajout ou de l’importation d’utilisateurs. Pour un utilisateur existant, les administrateurs peuvent aller à la page de l’utilisateur et cliquer sur l’option activation/désactivation de l’option SAML SSO pour un utilisateur et sélectionner un fournisseur d’identité. Un utilisateur peut être autorisé pour s’autentifier via un seul IdP.

La méta-donnée de CloudStack du fournisseur de service est accessible en utilisant la commande d’API getSPMetadata ou depuis l’URL http://acs-server:8080/client/api?command=getSPMetadata où acs est le nom de domaine ou l’adresse IP du serveur de gestion. L’administrateur de l’IdP peut obtenir la métadonnée du SP depuis CloudStack et l’ajouter à son serveur IdP.

Pour commencer une authentification Single Sign-On SAML 2.0, les utilisateurs, depuis la page de connexion, doivent sélectionner le fournisseur d’identité ou l’institution/département avec lequel ils peuvent s’authentifier et cliquer sur le bouton Connexion. Cette action appelle la commande d’API samlsso qui va rediriger l’utiliser à la page de connexion du fournisseur d’identité. Après une authentification réussie, l’IdP va rediriger l’utilisateur vers CloudStack. Dans le cas ou un utilisateur dispose de plusieurs comptes avec le même nom d’utilisateur (sur plusieurs domaines) pour le même IdP autorisé, cet utilisateur devra spécifier le chemin du domaine après avoir sélectionner son serveur IdP depuis la liste de choix. Par défaut, les utilisateurs n’ont pas besoin de spécifier un chemin de domaine. Après qu’un utilisateur soit authentifié avec succès par un serveur IdP, le plugin d’authentification SAML trouve les comptes utilisateurs dont le nom d’utilisateur correspond à l’attribut nom d’utilisateur retourné par la réponse d’authentification SAML ; ceci échoue seulement lorsqu’il trouve qu’il existe plusieurs comptes utilisateurs avec le même nom d’utilisateur pour cet IdP spécifiquement et dans les autres cas le compte utilisateur unique est autorisé, et l’utilisateur est connecté à son compte.

Limitations :

Le plugin utilise l’attribut utilisateur retourné par le serveur IDP dans la réponse SAML pour trouver et associer l’utilisateur autorisé dans CloudStack. L’attribut par défaut est uid.
Le plugin d’authentification SAML support les authentifications HTTP-Redirect et HTTP-Post.
Testé avec Shibboleth 2.4, SSOCircle, Microsoft ADFS, OneLogin, Feide OpenIDP, PingIdentity.

La configuration globale suivante doit être effectuée :

saml2.enabled: Indique si le plugin SAML SSO est activé ou non. La valeur par défaut est false
saml2.sp.id: chaîne de l’identifiant du fournisseur de service SAML2
saml2.idp.metadata.url: URL du fichier de méta-données du fournisseur d’identité SAML2 ou nom de fichier . Si une URL est fournie, il cherchera un fichier dans le répertoire de configuration /etc/cloudstack/management
saml2.default.idpid: L’ID par défaut du fournisseur d’identité (IdP) à utiliser seulement dans le cas de multiples fournisseurs d’identités.
saml2.sigalg: L’algorithme à utiliser lors de la signature de requêtes SAML. Par défault l’algorithme est SHA1, les algorithmes autorisés sont : SHA1, SHA256, SHA384, SHA512.
saml2.redirect.url: L’URL de l’interface CloudStack vers lequel le SSO doit rediriger après un succès. L’URL par défaut est http://localhost:8080/client
saml2.sp.org.name: Nom de l’organisme du fournisseur de service SAML2
saml2.sp.org.url: URL de l’organisme du fournisseur de service SAML2
saml2.sp.contact.email: Adresse email de contact du fournisseur de service SAML2
saml2.sp.contact.person: Nom du contact du fournisseur de service SAML2
saml2.sp.slo.url: URL de déconnexion du fournisseur de service SAML2
saml2.sp.sso.url: URL Single Sign On du fournisseur de service SAML2 CloudStack
saml2.user.attribute: Nom de l’attribut à rechercher dans la réponse SAML qui contient le nom d’utilisateur. La valeur par défaut est uid
saml2.timeout: Interval de temps de rafraîchissement en secondes des méta-données du fournisseur d’identité SAML2, la valeur minimale est fixée à 300. La valeur par défaut est 1800.