Ubuntu Girl
  1. Ubuntu Girl
  3. Comment gérer plusieurs administrateurs avec juju?
Intereting Posts
Problèmes d’interface graphique MythTV Fichier global git config – Supprimer les parameters Comment append plusieurs espaces de travail dans Unity 2D? Comment démarrer à partir d’ubuntu live usb avec ‘try ubuntu’ directement? Dois-je installer un logiciel antivirus? Comment utiliser les deux boutons de la souris simultanément en tant que clic du milieu? Comment synchroniser OneDrive Business / Office 365 sur Linux? Le pavé tactile ne fonctionne pas dans Ubuntu 12.04 Impossible d’installer VLC et d’autres programmes en raison de problèmes de dépendance étranges Problème lors de la gravure du fichier ISO sur le disque Comment supprimer le raccourci d’application Web créé par le chrome? Comment définir le délai d’expiration de grub et l’entrée de démarrage par défaut de grub? Python comparé à BASH Comment puis-je charger Ubuntu quand tout ce que j’ai est Grub? Comment créer un DVD à partir d’un fichier vidéo?

Comment gérer plusieurs administrateurs avec juju?

Je gère certains déploiements avec juju. Cependant, je ne suis pas une île, j’ai des collègues qui veulent aussi gérer des environnements partagés.

Je sais que je peux utiliser la strophe suivante dans ~/.juju/environments.yaml pour donner aux gens un access à mon environnement juju: 

 authorized-keys: [and then put their ssh IDs in here]

Quelles sont les autres meilleures pratiques disponibles pour gérer plusieurs environnements avec plusieurs administrateurs système?

Juju n’est pas vraiment optimisé pour plusieurs administrateurs. En particulier, certains problèmes de sécurité actuellement rencontrés dans Juju deviennent plus prononcés lorsque vous travaillez avec plusieurs administrateurs. Toutefois, avec certaines réserves, cela peut restr une option utile pour un groupe d’administrateurs de confiance, et donc probablement petit.

Dans cet esprit, examinons les éléments de configuration pertinents du fichier ~/.juju/environment.yaml .

L’élément authorized-keys est utilisé dans l’environnement d’amorçage pour définir les clés SSH publiques de l’utilisateur Ubuntu sur le nœud d’amorçage (machine 0, sur laquelle ZooKeeper s’exécute) et tous les nœuds provisionnés par la suite. Il suffit de lister une clé publique autorisée par ligne. Cela ressemblera à ceci: 

 authorized-keys: | ssh-rsa AAAblahblahZZZZ user@domain ecdsa-sha2-nistp256 AAAAfoobarZZZZ= user2@domain

Cette approche est préférable à l’utilisation de authorized-keys-path – ou de sa valeur par défaut ( ~/.ssh/ ) – qui ne convient que pour un seul administrateur, étant donné que vous devrez alors partager les clés SSH (ne le faites pas!). En termes simples, il ne s’agit que d’une limitation de la mise en œuvre du authorized-keys-path .

Ensuite, les fournisseurs de cloud définissent leurs identifiants de sécurité spécifiques, que Juju utilise ensuite. À titre d’exemple, examinons EC2, en particulier AWS. Pour AWS, deux clés sont utilisées pour déterminer l’access: access-key secret-key , correspondant aux variables d’environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY (ce sont les valeurs par défaut si elles ne sont pas spécifiées dans le fichier de configuration). Le défi ici pour un environnement à plusieurs administrateurs – ou même un environnement à un seul administrateur – est que ces informations sont copiées dans ZooKeeper et sont facilement visibles dans le nœud /environment ZK. Voir le bogue Juju n ° 907094 .

Dans l’exemple AWS, vous pouvez utiliser un certain degré de contrôle sur vos clés d’access via l’utilisation de la FAQ d’AWS Identity and Access Management (recherche), mais il n’existe actuellement aucun mécanisme permettant de fournir un contrôle plus fin à un administrateur donné en un environnement Juju.

Il convient de noter un motif supplémentaire observé dans notre propre utilisation, notamment dans les tests: un environnement Juju (“contrôle”) configuré sur un nœud donné pour contrôler d’autres environnements Juju; déployez simplement le charme de juju pour avoir cette configuration. Il faut comme option de configuration le fichier environment.yaml à utiliser. Des administrateurs supplémentaires peuvent ensuite être autorisés ultérieurement en tant qu’utilisateur d’ ubuntu en ajoutant manuellement leurs clés à ~ubuntu/.ssh/authorized-keys .

Cela permet à un seul sharepoint gérer certaines de ces préoccupations tout en minimisant les maux de tête. Cela ne résout en rien les problèmes de sécurité mentionnés plus haut – vous devez toujours avoir une confiance relativement profonde de vos autres administrateurs.

Juju resynchronisera environments.yaml sur le nœud /environment ZK lors de l’utilisation de certaines commandes ( juju add-unit juju constraints-get juju constraints-set juju deploy juju constraints-set , juju deploy juju terminate-machine ). Dans la pratique, cela ne sera pas très utile – sauf pour son utilisation réelle, ses contraintes. Cependant, cela peut aider à minimiser le besoin de mettre à jour les fichiers de clés autorisées, car toutes les machines nouvellement provisionnées après la synchronisation l’obtiendront. vous ne seriez alors que responsable de la mise à jour des machines précédemment provisionnées.

Bien que je sois sur ce point, il convient de noter comment et où les ~ubuntu/.ssh/authorized-keys sont réellement utilisées:

  • Toutes les commandes de contrôle Juju, à deux exceptions près, utilisent un tunnel SSH vers l’instance ZooKeepeer pour gérer ou rechercher des informations à partir de l’environnement Juju. ( juju bootstrap et juju destroy-environment fonctionnent directement avec l’API de fournisseur de nuage sous-jacente.) Il est donc impératif de conserver les authorized-keys sur la machine 0 actuelle.

  • juju ssh et juju scp permettent de travailler directement avec une machine. Ils doivent également disposer authorized-keys actuelles que vous devrez envisager de mettre à jour dans le cas des administrateurs multiples. Ces commandes utilisent par défaut l’utilisateur ubuntu sur la machine cible.