Présentation des Tenants – Part 12

Présentation des Tenants – Part 12

Un Tenant est une unité organisationnelle dans un déploiement vRealize Automation.

Un Tenant représente une unité d’organisation dans une entreprise ou une entreprise qui s’abonne aux services de cloud d’un fournisseur de services.

Chaque tenant dispose de sa propre configuration dédiée. Une partie de la configuration au niveau système est partagée entre les tenants.

Configuration d’un Tenant :

Url de login : Chaque Tenant dispose d’une URL permettant une connexion à sa console vRealize Automation.

  • L’URL pour un mode Single Tenant par défaut est :
    https://vra-hostname-fqdn/vcac
  • L’URL pour un mode Multi Tenant est : https://vra-hostname-fqdn/vcac/org/tenantURL

 Identify Stores : Chaque Tenant accède à un ou plusieurs services d’annuaire, comme Open LDAP ou Active Directory afin d’authentifier les utilisateurs. Il est possible d’utiliser le même pour un ou plusieurs tenants mais la configuration doit être réalisée séparément pour chaque tenant.

 Branding : Un Tenant Administrator  peut configurer le branding appliqué par défaut au Tenant. Il s’agit simplement du logo, de la couleur d’arrières plan et des informations figurant dans l’en-tête et le pied de page du tenant.

 Notification Providers : Les system administrators  peuvent configurer les serveurs de messagerie traitant les notification par mail. Les Tenant Administrators peuvent remplacer les serveurs par défaut du système ou ajouter leurs propres serveurs si aucun serveur global n’est spécifié.

Business Policies : L’administrateur de chaque tenant peut configurer les business policies, les workflows d’approbation et aussi les droits pour leur tenant. Il faut savoir que les business policies sont spécifiques à chaque tenant.

 Service Catalog Offerings : Les Service Architect  peuvent créer et publier des objets du catalogue dans le catalogue de service. Ils peuvent aussi les attribuer à des catégories de services. Les services et objets du catalogue sont spécifiques à chaque Tenant.

 Infrastructure Ressources : Les ressources d’infrastructure sous-jacente (fabric), comme par exemple vCenter Server, Amazon, sont partagées par tous les Tenants. Pour chaque infrastructure que gère vRealize Automation, une partie des ressources peut être réservée aux utilisateurs d’un tenant spécifique.

Le default tenant :

Lorsque le system administrator configure SSO pendant l’installation de vRealize Automation, un tenant par défaut est créé avec le compte de system administrator intégré. Cela afin de pouvoir ouvrir une session dans la console vRealize Automation.

Le system administrator peut ensuite configurer le tenant par défaut et créer des nouveaux tenants supplémentaires.

Le tenant par défaut prend en charge toutes les fonctions décrites dans « Configuration d’un tenant ». Le défault tenant est le seul tenant prenant en charge l’authentification Active Directory native. Tous les autres tenants doivent utiliser Active Directory via LDAP ou un annuaire libre de type OpenLdap.

Le system administrator effectue la configuration initiale de Single Sign-On et la configuration de base du tenant, notamment la désignation d’au moins un Identify Store et un tenant administrator pour chaque tenant.

Les Tenant Administrators peuvent créer au sein de leur propre tenant des groupes personnalisés et y ajouter des utilisateurs et des groupes définis dans le Store Identify. Les groupes personnalisés, comme les groupes de Store Identify et les utilisateurs, peuvent se voir attribuer des rôles ou être désignés comme approbateurs (Approver) dans une stratégie d’approbation (Approval policy).

Ils peuvent créer des Business groups dans leur tenant. Un business group est un ensemble d’users correspondant à un secteur d’activité, un service ou une unité d’organisation pouvant être associé à un ensemble de catalogue de services et de ressource d’infrastructure.

Comparaison entre un déploiement single tenant et multi tenant :

La configuration peut varier selon le nombre de tenants inclus dans le déploiement.

  • Déploiement Single tenant :

Dans un déploiement single tenant, l’ensemble de la configuration peut s’effectuer dans le tenant par défaut. Les Tenants Administrators peuvent gérer les utilisateurs, les groupes, configurer les informations de branding spécifiques au tenant, les notifications (Notification Providers), les stratégies d’entreprise (Business Policies) et les offres du catalogue (Service Catalog Offerings).

Tous les utilisateurs ouvrent une session sur la console vRealize Automation à la même URL, mais les fonctionnalités auxquelles ils ont accès sont déterminées par leurs rôles.

Exemple de Single Tenant :


En Single Tenant, il est courant que les rôles d’administrateur système (System Administrator) et d’administrateur du tenant (tenant administrator) soient attribués à la même personne, parfois sous la forme de deux comptes distincts mais la plupart du temps il s’agit du Tenant Administrator.

Le compte « System Administrator » est toujours administrator@vsphere.local

Le Tenant Administrator  doit être utilisateur de l’un des magasins d’identités de tenant (Identify Stores ), comme username@mycompany.com.

  • Déploiement Multi tenants
  • Multitenant avec configuration de l’infrastructure uniquement dans le Default Tenant

Nous avons dans ce schéma une configuration multi tenant avec centralisation de l’administration de l’infrastructure. L’administrator IaaS dans le défaut tenant, configure toute l’infrastructure disponible pour tous les tenants. L’administrator IaaS organise l’infrastructure en Fabric Group. Puis, le Fabric Administrator pour chaque Fabric Group peut allouer les ressources pour son Fabric Group. Bien que le Fabric Administrator existe seulement dans le defaut tenant, il peut assigner des ressources à des Business Group de n’importe qu’elle tenant.


  • Multitenant avec configuration de l’infrastructure sur chaque Tenant

Nous avons dans ce schéma une configuration multi tenant ou chaque tenant administre son infrastructure. L’administrator system est le seul utilisateur qui peut se connecter sur le defaut tenant pour manager la configuration des rôles systèmes (System Wide) et créer des tenants.

Chaque tenant possède un Administrator IaaS qui peut créer les Fabric Group et affecter les Fabric Administrator dans leur tenant respectif. Bien que les Fabric administrators peuvent créer des réservations pour les Business Group dans tous les tenants, dans cet exemple, ils créent et gèrent des réservations dans leurs propres tenants.


Rôles et utilisateurs :

Les rôles sont des ensembles de privilèges qui peuvent être attribués aux utilisateurs afin de déterminer les tâches qu’ils peuvent exécuter. En fonction de leurs responsabilités, les utilisateurs peuvent disposer d’un ou de plusieurs rôles associés à leur compte utilisateur.

Dans vRealize Automation il existe:

  • des rôles systèmes (System Wide)
  • des rôles Tenant (Tenant Wide)

Rôles (System-Wide)

  • System Administrator : Le system administrator est la personne qui installe vRealize Automation et s’assure des accès utilisateurs. Le system administrator à les droits de création des Tenants et gestion de la configuration du global du système. Il est en charge de la surveillance des logs système.
  • IaaS administrator : Le IaaS administrator gère les endpoints, les accès aux endpoints, créer les Fabric groups et configure les agents.  Il gère aussi les comptes de service cloud, les machines physiques et le stockage. Il surveille aussi les logs spécifiques à IaaS.
  • Fabric administrator : Le Fabric Administrator administre un ou plusieurs Fabric Groups. Il gère les machines physiques, les ressources associées à ses groupes, les réservations et la politique de réservations associées à ces ressources. Il gère également la création des profils, les préfixes machines et les propriétés du dictionnaire utilisées dans l’ensemble des tenants et des Business Group

Récapitulatif des actions pour chaque rôle :

 Rôle Responsabilités Assignation
System administrator
  • Créer des Tenants
  • Configurer les identity stores des tenants
  • Assigner le rôle IaaS administrator
  • Assigner le rôle Tenant Administrator
  • Configurer le branding par défaut
  • Configurer les provider de notifications par défaut
  • Surveiller les logs
  • Configurer vRealize Orchestrator pour utiliser Advanced Services Designer
Crédentials du system administrator spécifiés lors de la configuration du Single Sign On (Identity Appliance)

Dans notre cas : administrator@vsphere.local

IaaS administrator
  • Configurer les fonctionnalités IaaS
  • Gérer les licences IaaS
  • Créer et gérer les fabric groups
  • Créer et gérer les endpoints
  • Gérer les crédentials des endpoints
  • Configurer les agents proxy
  • Gérer les instances de type Amazon AWS
  • Surveiller les logs IaaS
Le system administrator désigne l’administrateur IaaS lorsqu’il configure un Tenant

Dans notre cas, le groupe : adm-infra-compagny01@demo.local

Fabric Administrator
  • Gérer les build profiles
  • Gérer les ressources de calcul
  • Gérer les cost profiles
  • Gérer les network profiles
  • Gérer les volumes et paires de clés Amazon EBS
  • Gérer les préfixes de machine
  • Gérer le property dictionary
  • Gérer les réservations et les politiques de réservations
L’administrateur IaaS désigne l’administrateur de Fabric lorsqu’il créer ou modifie un fabric group.

Dans notre cas, le groupe : adm-fabric-compagny01@demo.local

– Rôle (Tenant-Wide)

Le rôle des tenants a une responsabilité limitée au tenant et ne peuvent pas affectés les autres tenants dans le système.

  • Tenant Administrator : Le tenant administrator configure vRealize Automation pour les besoins de son organisation. Il est responsable de la gestion des utilisateurs et groupes, du branding du tenant, des notifications et des business policies. Il surveille l’utilisation des ressources par les utilisateurs du tenant et initie les requêtes de réclamation pour les machines Virtuelles.
  • Service Architect : Désigne les utilisateurs responsables de la création des blueprints et des objets du catalogue que les utilisateurs peuvent demander au sein du catalogue de service. Ce rôle est typiquement occupé par un architecte ou un analyste. Au sein de l’IaaS, les administrateurs du tenant ou les manager de business group peuvent créer des blueprints (mono ou multi-machines). Dans Application Services, les architectes applicatifs peuvent créer des blueprints applicatifs et des profils de déploiement. Dans Advanced Services Designer, les architectes Service peuvent créer des blueprints de services.
  • Business Group Manager : Gère un ou plusieurs Business Group. Typiquement un chef de projet. Il gère les objets du catalogue et les habilitations pour ses groupes dans le catalogue de services. Il peut faire des demandes et gérer les objets à la place des utilisateurs de ses groupes. Il est aussi Architecte Service au sein dans IaaS.
  •  Support User : C’est un rôle dans un business group. Il peut faire un demander et gérer les objets du catalogue à la place des utilisateurs de ses groupes.
  • Business User : Désigne tous les utilisateurs qui consomment des services IT. Le business user demande un objet du catalogue depuis le catalogue de services et gére les ressources qu’il a provisionnées.
  • Approval Administrator : Défini les politiques d’approbation. Ces règles peuvent être appliquées aux demandes dans le catalogue à travers des habilitations gérées par le tenant administrator ou le manager du business group.
  • Approver : Quelconque utilisateur de vRA, par exemple un responsable de finance, un chef de projet, qui est désigné comme approbateur au sein d’une politique d’approbation.

Récapitulatif des actions pour chaque rôle :

 Rôle Responsabilités Assignation
Tenant administrator
  • Gérer les identity stores des tenants
  • Gérer les rôles utilisateurs et groupes
  • Créer des groupes personnalisés
  • Personnaliser le branding du tenant
  • Gérer les providers de notifications
  • Activer les scénarios de notifications aux utilisateurs du tenant
  • Créer et gérer les règles d’approbation
  • Gérer le catalogue de services
  • Gérer les objets du catalogue
  • Gérer les actions
  • Gérer les habilitations
  • Surveiller les machines du tenant et envoyer des requêtes de réclamations
  • Configurer vRealize Orchestrator, plug ins, workflow pour l’utilisation dans Advanced Services Designer
  • Créer et publier les blueprints de machine partagés depuis IaaS
System Administrator désigne un administrateur de tenant lorsqu’il créer un tenant.

Tenant administrator peut assigner le rôle à d’autre utilisateur dans le tenant

Dans notre cas, le groupe : adm-tenant-compagny01@demo.local

Service Architect
  • Définir les types de ressources personnalisées
  • Créer et publier des blueprints service depuis Advanced Services Designer
  • Créer et publier des actions personnalisées
Le tenant administrator peut assigner ce rôle à des utilisateurs ou groupes.
Application Architect
  • Créer, modifier et supprimer les applications dans Application Services
Le tenant administrator peut assigner ce rôle à des utilisateurs ou groupes. L’utilisateur ou le groupe doit être au préalable enregistré dans le tenant avec Application Service
Application Catalog Administrator
  • Définir les services, templates, OS, tâches et tags dans la librairie Application Service
Le tenant administrator peut assigner ce rôle à des utilisateurs ou groupes. L’utilisateur ou le groupe doit être au préalable enregistré dans le tenant avec Application Service
Application Cloud Administrator
  • Définir les environnements de ressources et de déploiement
Le tenant administrator peut assigner ce rôle à des utilisateurs ou groupes. L’utilisateur ou le groupe doit être au préalable enregistré dans le tenant avec Application Service
Application publisher and developer
  • Déployer les applications dans le catalogue de vRealize Automation
  • Créer, mettre à jour et publier des services, objets et actions dans Application Services
Le tenant administrator peut assigner ce rôle à des utilisateurs ou groupes. L’utilisateur ou le groupe doit être au préalable enregistré dans le tenant avec Application Service
Business Group Manager
  • Créer et publier des blueprints machine spécifiques au business group depuis IaaS
  • Gérer les objets du catalogue spécifiques au business group et les habilitations
  • Surveiller l’utilisation des ressources dans le business group
Le tenant administrator désigne le business group manager quand il créer ou modifie un business group
Support User
  • Demande et gère les objets à la place des utilisateurs dans ses business group
Le tenant administrator désigne le support user quand il créer ou modifie un business group
Business User
  • Demande et gère les services
Le tenant administrator désigne les business users qui peuvent consommer des services IT quand il créer ou modifie un business group
Approval administrator
  • Créer et gérer les règles d’approbations
Le tenant administrator peut assigner le rôle à un utilisateur ou groupe pour gérer les règles d’approbation
Approver
  • Approuve les demandes effectuées depuis le catalogue dont les demandes de provisonnement et les actions sur les ressources
Le tenant administrator ou approval administrator créer les approval policies et désigne les approvers pour chaque policy

 Voici un schéma représentant la configuration d’un tenant :



twitterlinkedin
Tagués avec : , , , , , , , , , , , , , , , , , , , ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*