Sécurité du gestionnaire de travaux
Dans un environnement de gestion souple, un ID utilisateur doit disposer des autorisations requises pour utiliser le gestionnaire de travaux et les noeuds enregistrés.
Rôles de sécurité requis
Les rôles suivants sont nécessaires pour utiliser le gestionnaire de travaux :
Tâches d'administration | Rôles de sécurité requis |
---|---|
Enregistrer ou annuler l'enregistrement auprès du gestionnaire de travaux | administrateur |
Soumettre un travail | opérateur |
Modifier la configuration du gestionnaire de travaux | configurateur |
Lire la configuration ou l'historique des travaux du gestionnaire de travaux | contrôler |
Si les noeuds de serveur d'applications de base (autonome) gérés par un agent d'administration sont enregistrés auprès d'un gestionnaire de travaux, les rôles suivants sont requis pour utiliser l'agent d'administration et gérer ses noeuds :
Tâches d'administration | Rôles de sécurité requis |
---|---|
Enregistrer ou annuler l'enregistrement d'un noeud (autonome) de base auprès de l'agent d'administration | administrateur |
Utiliser l'agent d'administration : | Rôles d'administration requis pour l'opération en cours d'exécution |
Utiliser le sous-système d'administration, par exemple les noeuds enregistrés | Rôles administratifs requis pour le noeud de base enregistré |
Lorsqu'un travail s'exécute sur une cible, l'utilisateur doit disposer des privilèges contenant le rôle requis pour ce travail. Par exemple, un travail consistant à créer un serveur d'applications requiert au minimum le rôle de configurateur sur le noeud de base ou sur la cellule WebSphere Application Server, Network Deployment.
Sécurité des travaux d'Installation Manager ou de Liberty sur des hôtes distants
Lorsqu'un nom d'utilisateur et un mot de passe sont requis pour l'accès à un hôte distant comme Installation Manager ou un Liberty, vous devez fournir un nom d'utilisateur et un mot de passe de système d'exploitation valides pour qu'un travail s'exécute sur l'hôte distant. Vous pouvez fournir les types d'autorisation suivants :
- Nom d'utilisateur et mot de passe du système d'exploitation
- Le nom d'utilisateur et le mot de passe sont les valeurs de connexion de l'hôte. Si l'hôte ne requiert pas de mot de passe, il n'est pas nécessaire de fournir un mot de passe lors de la soumission d'un travail.
- Sudo
- Si vous voulez qu'un autre utilisateur exécute des commandes sur l'hôte, vous pouvez utiliser sudo pour changer d'utilisateur avant l'exécution d'un travail et spécifier ensuite le nom d'utilisateur et le mot de passe de l'autre utilisateur. sudo signifie "exécuter en se substituant à l'utilisateur". Si l'hôte ne requiert pas de mot de passe, il n'est pas nécessaire de fournir un mot de passe lors de la soumission d'un travail.
- Authentification par clé publique-privée
- Vous pouvez utiliser l'authentification par clé publique-privée. Lors de la soumission d'un travail, vous spécifiez le chemin d'accès complet au fichier de clés et, si ce dernier l'exige, la phrase passe. Une clé privée SSH (Secure Shell) permet à un administrateur d'exécuter un travail sur l'hôte distant sous un nom d'utilisateur spécifique. La clé est chiffrée par mot de passe afin qu'elle ne soit pas utilisée par un utilisateur différent.
For Liberty servers, the type of authorization that you use depends upon the user names that are configured for each host:
- Nom d'utilisateur unique
- Si chaque hôte utilise un seul nom d'utilisateur, vérifiez uniquement que les répertoires dans lesquels les ressources du Liberty doivent être installées sont inscriptibles par l'utilisateur. Pour prendre en charge la soumission de travaux à des hôtes différents, vérifiez que le même nom d'utilisateur est configuré sur chaque hôte ou utilisez une clé SSH pour vous authentifier sous un nom d'utilisateur différent pour chaque hôte.
- Passage à un nom d'utilisateur unique
- Si les hôtes prennent en charge plusieurs noms d'utilisateur, vous pouvez soumettre les travaux sous des noms d'utilisateur différents, mais utilisez sudo pour passer à un nom d'utilisateur commun unique. Seul le nom d'utilisateur commun peut gérer des ressources du Liberty. Ce nom d'utilisateur est souvent configuré pour désactiver la connexion.
- Noms d'utilisateur différents
- Dans certaines configurations, vous pouvez installer chaque ressource du Liberty sous un nom d'utilisateur de système d'exploitation différent. Par exemple, les ressources partagées peuvent être installées sous un ou plusieurs noms d'utilisateur et mises à disposition en lecture seule au niveau global ou pour un groupe de systèmes d'exploitation spécifique. Des ressources de travail non partagées peuvent être créées exclusivement pour des noms d'utilisateur différents.
Vous pouvez contrôler qui peut installer les ressources du Liberty en contrôlant les droits d'accès aux fichiers du répertoire racine pour chaque ressource. Si vous définissez le répertoire comme étant inscriptible par un seul utilisateur, seul ce dernier peut effectuer l'installation dans ce répertoire. Si vous définissez le répertoire comme étant inscriptible par un groupe d'utilisateurs, les utilisateurs appartenant à ce groupe peuvent installer des ressources sous le répertoire racine. Si vous définissez le répertoire comme étant inscriptible au niveau global, tous les utilisateurs peuvent effectuer l'installation dans ce répertoire.
Au cours de l'installation, vous pouvez définir des droits d'accès aux fichiers qui empêchent d'autres utilisateurs de modifier les ressources. Par exemple, vous pouvez précréer ${WLP_WORKING_DIR}/project1 avec des droits d'accès aux fichiers de manière à ce qu'il soit inscriptible par un utilisateur ou un groupe spécifique uniquement. Une fois que l'utilisateur a installé un nouveau Liberty, comme server1, vous pouvez configurer ${WLP_WORKING_DIR}/project1/server1 de manière à ce qu'il ne puisse pas être remplacé par un utilisateur différent.
Lorsque plusieurs utilisateurs peuvent accéder à des ressources, vous devez définir des variables ou des paramètres de travaux qui permettent à un travail d'inventaire de trouver toutes les ressources disponibles :
- Vous devez définir la variable WLP_ADDITIONAL_DIRS afin que la recherche des ressources s'effectue dans tous les chemins appropriés ; ou
- Vous devez vous assurer que toutes les ressources sont lisibles par le nom d'utilisateur employé pour exécuter le travail d'inventaire. Les ressources doivent être créées comme étant lisibles au niveau global, les ressources doivent être lisibles au niveau du groupe de systèmes d'exploitation avec le nom d'utilisateur appartenant au groupe, ou le nom d'utilisateur racine doit être utilisé pour exécuter le travail d'inventaire.
Configuration de sécurité de base
L'agent d'administration et le gestionnaire de travaux prennent en charge deux configurations de sécurité de base différentes :
Pour la topologie de l'agent d'administration, lorsqu'un utilisateur se connecte au port de connecteur JMX d'un sous-système d'administration ou qu'il sélectionne le noeud enregistré dans la console d'administration, la table d'autorisation du noeud sélectionné est utilisée.
Par exemple, supposons qu'Utilisateur1 dispose de droits d'accès en tant qu'administrateur pour le premier noeud de base mais pas pour le second. Utilisateur2 dispose de droits d'accès en tant que configurateur pour le second noeud mais pas pour le premier. La figure Même registre d'utilisateurs illustre cela :

Supposons également qu'Utilisateur1 puisse se connecter au gestionnaire de travaux en tant qu'opérateur avec un nom d'utilisateur et un mot de passe. Utilisateur1 peut également se connecter au gestionnaire de déploiement en tant que surveillant avec un nom d'utilisateur et un mot de passe. La figure Registres d'utilisateurs différents illustre cet exemple :

Bien qu'Utilisateur1 ait le même nom d'utilisateur sur le gestionnaire de travaux et le gestionnaire de déploiement, il peut aussi avoir des noms d'utilisateur et des mots de passe différents.
Transfert des informations de sécurité
Lorsque le produit transfère un travail depuis le gestionnaire de travaux vers l'agent d'administration, le gestionnaire de déploiement ou le système hôte, il transfère également les informations de sécurité relatives à l'émetteur du travail. Ce transfert authentifie et autorise l'utilisateur tout en exécutant le travail. Les informations de sécurité utilisateur suivantes peuvent être transmises avec un travail soumis :
- Nom d'utilisateur
et mot de passe
Lors de la soumission d'un travail, l'utilisateur peut indiquer un nom d'utilisateur et un mot de passe. Lorsque le travail atteint le sous-système d'administration ou le gestionnaire de déploiement, le nom d'utilisateur et le mot de passe sont utilisés pour la connexion.
En ce qui concerne la configuration du même registre d'utilisateurs, si Jean soumet un travail sur le premier noeud de base, il peut spécifier son nom d'utilisateur et son mot de passe dans le cadre du travail. Le nom d'utilisateur et le mot de passe permettent de se connecter au premier sous-système d'administration et le travail est exécuté. Si Jean soumet un travail sur la cellule du gestionnaire de déploiement ou sur le second noeud de base, le travail échoue car Jean ne dispose pas des autorisations requises.
Dans le cas de la configuration de registres d'utilisateurs différents, Jean peut soumettre un travail sur la cellule de gestionnaire de déploiement en indiquant son nom d'utilisateur et son mot de passe pour la cellule de gestionnaire de déploiement. Lorsque le travail atteint le gestionnaire de déploiement, la connexion aboutit et le travail est exécuté. Si Jean soumet un travail sur les noeuds de base, l'accès est refusé et le travail échoue.
- Jeton de sécurité
Si l'utilisateur n'indique pas de nom d'utilisateur et de mot de passe pour un travail, ses données d'identification sont automatiquement conservées en tant que jeton de sécurité dans la base de données des travaux. Le jeton contient les attributs de sécurité de l'utilisateur, y compris les groupes. Lorsqu'un travail est extrait, le jeton permet l'authentification et la validation sur le sous-système d'administration ou le gestionnaire de déploiement.
En ce qui concerne la configuration du même registre d'utilisateurs, Jean peut soumettre un travail sur le premier noeud de base sans indiquer un nom d'utilisateur et un mot de passe. Le travail s'exécute car les données d'identification de Jean sont automatiquement propagées en tant que jeton de sécurité au sous-système d'administration et utilisées pour l'authentifier et l'autoriser à exécuter le travail. Si Jean soumet un travail sur le second noeud de base ou la cellule de gestionnaire de déploiement, ce travail échoue car son jeton de sécurité n'est pas autorisé dans ces deux environnements.
Dans le cas de la configuration de registres d'utilisateurs différents, le jeton de sécurité d'un utilisateur n'autorise pas automatiquement le travail soumis à s'exécuter sur le sous-système d'administration ou le gestionnaire de déploiement. Pour activer un jeton utilisateur sur un domaine différent, vous devez utiliser la fonction de domaines de sécurité multiples. Vous devez d'abord établir le domaine du gestionnaire de travaux en tant que domaine sécurisé pour les noeuds de base enregistrés et la cellule de gestionnaire de déploiement. En outre, vous devez importer l'ID d'accès de l'utilisateur du gestionnaire de travaux dans la table des autorisations locales et attribuer un rôle à cet ID. L'utilisateur peut alors soumettre un travail sans entrer de nom d'utilisateur ni de mot de passe.
Supposons que Jean soit un opérateur sur le gestionnaire de travaux, mais que son ID d'accès soit importé en tant qu'administrateur dans la table des autorisations administratives du premier noeud de base. Bien que Jean n'existe pas dans le registre d'utilisateurs du noeud de base, en transmettant le jeton de sécurité et la définition de la table des autorisations administratives, John est validé en tant qu'administrateur sur le noeud de base. Jean peut soumettre un travail pour le premier noeud de base sans avoir à spécifier de nom d'utilisateur ni de mot de passe.
Si Jean soumet un travail sur le gestionnaire de déploiement, ce travail échoue. Le jeton de sécurité de Jean provient du domaine du gestionnaire de travaux et son ID d'accès n'a pas été autorisé sur le gestionnaire de déploiement. Dans ce cas, l'administrateur peut exporter l'ID d'accès de Jean du gestionnaire de travaux et l'importer dans le gestionnaire de déploiement. Jean peut aussi soumettre un travail en indiquant le nom d'utilisateur et le mot de passe utilisés pour le gestionnaire de déploiement, ce qui lui permet d'exécuter des travaux avec son rôle de surveillant.
Il est en de même si la fonction de sécurité à granularité fine est utilisée. Vous devez disposer des autorisations requises dans la table d'autorisations pour un nouveau groupe d'autorisations. Il se peut que la table d'autorisations contienne également un ID d'accès externe.
Configuration de registres mixtes
Dans une topologie plus complexe, où des cellules partagent le même registre d'utilisateurs et d'autres pas, les règles suivantes s'appliquent :