e-Xpert Solutions Lausanne
Auteur : Gilliek
Date de publication : 22 décembre 2021 - Dernière mise à jour : 22 décembre 2021
Le scénario présenté ci-dessous fourni aux utilisateurs standards la possibilité de demander la création d’objets sur des équipements F5. Le ou les administrateur(s) peuvent alors valider la demande et l’accepter ou la refuser en ajoutant la raison du choix. De plus, si cette dernière est acceptée, l’objet sera alors créé sur F5.
Cet exemple à pour but de rester simple, mais il est bien entendu possible de le pousser bien plus loin. Lors d’une implémentation dans un environnement réel, il serait par exemple intéressant d’offrir aux utilisateurs un formulaire simplifié afin d’abstraire au maximum les détails de fonctionnement du F5. Pourquoi pas raisonner en termes d’application plutôt que de virtual server ? Et plutôt que de sélectionner le FQDN du F5 sur lequel déployer l’objet, sa zone (DMZ, …) ?
Il est également important de noter que dans cet exemple nous allons démontrer ce use-case sur des virtual servers, mais cela peut fonctionner sur n’importe quel type d’objet.
Pour implémenter ce use-case, nous allons utiliser la solution que nous avons développé en interne « Analytics Tool for F5 ».
Le schéma ci-dessous décrit comment le use-case va fonctionner :
Nous avons ici 2 acteurs : un utilisateur et un administrateur. L’utilisateur se connecte sur la solution et accède au dashboard pour soumettre de nouvelles demandes.
Ce dashboard lui est personnel, il n’a donc accès qu’à ses propres demandes. L’utilisateur remplit un formulaire de demande de création d’objet depuis le dashboard directement en cliquant sur le bouton « + REQUEST » :
La demande est alors enregistrée dans une base de données locale. Un log d’audit est ensuite créé et 2 notifications sont envoyées : La première à l’utilisateur, pour confirmer que la demande a bien été enregistrée. La seconde à l’administrateur pour l’inviter à valider la demande.
L’administrateur reçoit donc l’email et accède à son dashboard administrateur où il voit toutes les demandes ainsi que leur statut.
Il voit alors la nouvelle demande et peut la valider.
Il a le choix d’accepter ou de refuser la demande. Le statut va alors être mis à jour dans la base de données locale puis un log d’audit va être généré. Si la demande est acceptée, l’objet va être créé sur le F5. Des emails de notifications vont alors être envoyés à l’utilisateur et à l’administrateur.
Au niveau de notre produit, les objets suivants ont dû être créés pour mettre en place ce workflow :
Un index a été créé pour stocker les logs d’audit générés. Cela permet de rechercher facilement toutes les actions qui ont été faites, par qui, à quelle heure, etc.
Cet index pourrait être exploité pour faire un dashboard.
Il nous a fallu créer 2 « wizards ». Le premier pour que l’utilisateur puisse soumettre la demande. Ce wizard a un iscript attaché qui va se charger de valider les paramètres fournis par l’utilisateur, d’enregistrer la demande dans la base de données locale puis de créer le log d’audit correspondant. Le second pour que l’administrateur puisse valider la requête de l’utilisateur. Ce wizard récupère la demande de l’utilisateur et l’affiche à l’administrateur ainsi que des options supplémentaires pour accepter/refuser la demande. Il a également un iscript attaché afin de pouvoir mettre à jour l’entrée dans la base de données locale et générer un log d’audit local.
On a aussi besoin d’un workflow qui reçoit en temps réel chaque log d’audit :
L’idée de ce workflow est de trapper les logs d’audit, et en fonction du type d’action (request, approved ou denied) envoyer un email de notification à l’utilisateur et à l’administrateur.
Par exemple, un nœud conditionnel ressemble à ça :
Et un template d'email:
Finalement, on a besoin de 2 dashboards. Le premier pour l’utilisateur, qui n’affichera que les demandes de l’utilisateur courant en utilisant les informations de l’utilisateur connecté pour filtrer les informations affichées. Ce dashboard fournit un bouton qui déclenche le wizard créé précédemment afin que l’utilisateur puisse soumettre sa demande. Le second pour l’administrateur afin d’afficher la liste de toutes le demandes (en cours et passées) avec leur statut. De plus, il fournit un menu pour chaque demande et qui déclenche le wizard correspondant afin que l’administrateur puisse valider la demande.
Nous avons vu qu’il était possible de créer depuis notre solution tout un workflow pour gérer la validation de demandes de création d’objets F5 par des utilisateurs ainsi que d’automatiser la création desdits objets.
Pour plus d’information concernant ce use-case et sa mise-à-place, n’hésitez par à nous contacter via le formulaire de contact sur notre site web ou via notre support.
Pensez aussi à consulter nos autres use-cases pour la solution « Analytics Tool for F5 »
Events
Archives