Dans les articles précédents de cette série de blogs, nous avons couvert le déploiement du clustering/réplication (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), la gestion et la surveillance de vos bases de données et clusters existants, la surveillance des performances et de la santé, comment rendre votre configuration hautement disponible via HAProxy et MaxScale, comment vous préparer contre les catastrophes en planifiant des sauvegardes, comment gérer vos configurations de base de données et dans le dernier message comment gérer vos fichiers journaux.
L'un des aspects les plus importants pour devenir un administrateur de base de données de ClusterControl est de pouvoir déléguer des tâches aux membres de l'équipe et de contrôler l'accès aux fonctionnalités de ClusterControl. Ceci peut être réalisé en utilisant la fonctionnalité de gestion des utilisateurs, qui vous permet de contrôler qui peut faire quoi. Vous pouvez même aller plus loin en ajoutant des équipes ou des organisations à ClusterControl et en les mappant à vos rôles DevOps.
Équipes
Les équipes peuvent être considérées soit comme une organisation complète, soit comme des groupes d'utilisateurs. Les clusters peuvent être attribués à des équipes et, de cette manière, le cluster n'est visible que pour les utilisateurs de l'équipe à laquelle il a été attribué. Cela vous permet de gérer plusieurs équipes ou organisations au sein d'un environnement ClusterControl. Évidemment, le compte administrateur ClusterControl pourra toujours voir et gérer tous les clusters.
Vous pouvez créer une nouvelle équipe via le menu latéral -> Gestion des utilisateurs -> Équipes et en cliquant sur le signe plus sur le côté gauche sous la section Équipes :
Après avoir ajouté une nouvelle équipe, vous pouvez affecter des utilisateurs à l'équipe.
Utilisateurs
Après avoir sélectionné l'équipe nouvellement créée, vous pouvez ajouter de nouveaux utilisateurs à cette équipe en appuyant sur le signe plus dans la boîte de dialogue de droite :
En sélectionnant le rôle, vous pouvez limiter la fonctionnalité de l'utilisateur à un super administrateur, un administrateur ou un utilisateur. Vous pouvez étendre ces rôles par défaut dans la section Contrôle d'accès.
Contrôle d'accès
Rôles standards
Dans ClusterControl, les rôles par défaut sont :Super Admin, Admin et User. Le super administrateur est le seul compte qui peut administrer des équipes, des utilisateurs et des rôles. Le super administrateur peut également migrer des clusters entre des équipes ou des organisations. Le rôle d'administrateur appartient à une organisation spécifique et peut voir tous les clusters de cette organisation. Le rôle d'utilisateur ne peut voir que les clusters qu'il a créés.
Rôles des utilisateurs
Vous pouvez ajouter de nouveaux rôles dans l'écran de contrôle d'accès basé sur les rôles. Vous pouvez définir les privilèges par fonctionnalité, que le rôle soit autorisé (lecture seule), refusé (refuser), gérer (autoriser les modifications) ou modifier (gestion étendue).
Si nous créons un rôle avec un accès limité :
Comme vous pouvez le voir, nous pouvons créer un utilisateur avec des droits d'accès limités (principalement en lecture seule) et nous assurer que cet utilisateur ne casse rien. Cela signifie également que nous pourrions ajouter ici des rôles non techniques tels que Manager.
Notez que le rôle Super Admin n'est pas répertorié ici car il s'agit d'un rôle par défaut avec le plus haut niveau de privilèges au sein de ClusterControl et ne peut donc pas être modifié.
Accès LDAP
ClusterControl prend en charge l'authentification Active Directory, FreeIPA et LDAP. Cela vous permet d'intégrer ClusterControl au sein de votre organisation sans avoir à recréer les utilisateurs. Dans des articles de blog précédents, nous avons décrit comment configurer ClusterControl pour s'authentifier auprès d'OpenLDAP, FreeIPA et Active Directory.
Une fois que cela a été configuré, l'authentification auprès de ClusterControl suivra le tableau ci-dessous :
Fondamentalement, la partie la plus importante ici consiste à mapper le groupe LDAP au rôle ClusterControl. Cela peut être fait assez facilement dans la page Paramètres LDAP sous Gestion des utilisateurs.
La boîte de dialogue ci-dessus mapperait DevopsTeam au rôle d'utilisateur limité dans ClusterControl. Ensuite, répétez cette opération pour tout autre groupe que vous souhaitez mapper. Après cela, tout utilisateur s'authentifiant auprès de ClusterControl sera authentifié et autorisé via l'intégration LDAP.
Réflexions finales
La combinaison de tout ce qui précède vous permet de mieux intégrer ClusterControl dans votre organisation existante, de créer des rôles spécifiques avec un accès limité ou complet et de connecter les utilisateurs à ces rôles. La beauté de ceci est que vous êtes maintenant beaucoup plus flexible dans la façon dont vous organisez votre infrastructure de base de données :qui est autorisé à faire quoi ? Vous pouvez par exemple confier la tâche de vérification des sauvegardes à un ingénieur de fiabilité du site au lieu de demander au DBA de les vérifier quotidiennement. Permettez à vos développeurs de vérifier les fichiers journaux MySQL, Postgres et MongoDB pour les corréler avec leur surveillance. Vous pouvez également autoriser un développeur senior à faire évoluer la base de données en ajoutant plus de nœuds/fragments ou demander à un ingénieur DevOps chevronné d'écrire des conseillers.
Comme vous pouvez le voir, les possibilités ici sont infinies, il ne s'agit que de savoir comment les débloquer. Dans la série de blogs Developer Studio, nous approfondissons l'automatisation avec ClusterControl et pour l'intégration DevOps, nous avons récemment publié CCBot.
