La gestion des utilisateurs sur les plateformes de collaboration et de gestion de projet est cruciale. Parmi ces plateformes, Azure DevOps est largement utilisé pour le suivi des tâches, le contrôle de version, et la gestion de projets.

Cependant, avec l'évolution des équipes et des projets, il peut arriver que certains comptes utilisateurs ne soient plus utilisés. Pour optimiser les ressources et assurer une utilisation efficace des licences, il est nécessaire de détecter et de gérer ces comptes inactifs de manière proactive. C'est là qu'intervient l'automatisation.

Introduction à Terraform pour Azure et Azure DevOps​

Dans le monde du développement logiciel et de la gestion d'infrastructures, l'automatisation joue un rôle crucial. Terraform, un outil puissant d'Infrastructure as Code (IaC), se présente comme une solution incontournable pour automatiser la création, la modification et la gestion de l'infrastructure de manière efficace et sécurisée. Spécifiquement pour Azure et Azure DevOps, Terraform offre la flexibilité nécessaire pour gérer non seulement les ressources d'infrastructure mais aussi les utilisateurs et leurs droits, simplifiant ainsi les tâches administratives complexes et répétitives.

Avantages de l'Infrastructure as Code pour la gestion des utilisateurs​

L'adoption de Terraform pour gérer les utilisateurs sur Azure présente plusieurs avantages significatifs :

Automatisation et cohérence
Avec Terraform, les équipes peuvent décrire l'infrastructure nécessaire à l'aide de code, permettant une création, une mise à jour et une suppression uniformes des ressources. Cette approche garantit que la configuration des utilisateurs et de leurs droits est cohérente à travers tous les environnements, éliminant les disparités souvent observées avec les méthodes manuelles.

Réduction des erreurs manuelles
En automatisant la création et la gestion des utilisateurs, Terraform réduit considérablement le risque d'erreurs humaines, telles que les oublis ou les configurations incorrectes. Cela contribue à une infrastructure plus sûre et plus fiable.

Versioning et traçabilité
La gestion de la configuration en tant que code permet de versionner facilement les définitions de l'infrastructure, offrant une traçabilité complète des modifications et la possibilité de revenir à des versions antérieures en cas d'erreur ou de besoin de restauration.

Azure DevOps est un service cloud de Microsoft dédié au développement logiciel collaboratif. En utilisant des méthodes agiles, il permet la gestion de projets de développement logiciel tout en offrant des services d'intégration continue et de déploiement continu (CI/CD). Ces services permettent la création de pipelines automatisés pour tester et déployer automatiquement le code source d'une application. Pour exécuter ces pipelines, des agents Azure DevOps sont nécessaires, pouvant être hébergés soit par Microsoft, soit par l'utilisateur, connus sous le nom d'agents selfhosted.

Pour des agents Azure Devops selfhosted il est possible d'utiliser des machines virtuelles mais il est également possible d'utiliser des conteneurs docker comme nous allons le voir ici. Attention néanmoins, les agents Docker sont plus limités que les machines virtuelles, notamment par leur impossibilité d'utiliser Docker dessus. Pour cela nous allons utiliser Terraform pour déployer nos agents Azure DevOps et notre container registry dans lequel nous stockerons notre image docker utilisée pour déployer nos agents Azure DevOps dockerisés.

Utilité​

Les agents Azure DevOps sont utilisés pour les déploiements sur Azure Pipelines afin d'exécuter les différentes tâches nécessaires pour déployer votre application. Il existe des agents publics, disponibles par défaut et fournis par Microsoft.

Toutefois, il est possible d'instancier ses propres agents privés. Ceux-ci permettent de s'affranchir de la limite de 10 agents gratuits utilisables simultanéments et pouvant tourner pendant 6 heures maximum qu'impose Microsoft.

Ces pools d'agents sont constitués d'un ensemble de machines virtuelles compatibles avec de l'autoscaling (Virtual Machine Scale Set) qui sont configurées pour exécuter des tâches de compilation, de test et de déploiement de code dans le cadre d'un pipeline Azure DevOps.

Avec AWS Cost Explorer, vous pouvez agréger les coûts en fonction de différents types de coûts AWS

En cherchant à comprendre à quoi correspondent les types de coûts proposés par AWS dans Cost Explorer, je n'ai trouvé que très peu de documentation sur le sujet. J'ai donc fait quelques recherches et tests pour essayer de mieux comprendre ce qui se cache derrière les coûts Unblended, Net Amortized et leurs déclinaisons.

Dans cet article, je tente donc de décrire chaque type de coûts disponible avec AWS Billing and Cost Management et je donne quelques bonnes pratiques pour vous aider à choisir le type de coûts qui vous convient le mieux.

Infracost qu'est ce que c'est ?​

Infracost est un outil open-source qui permet d'estimer les coûts des infrastructures cloud . Il s'agit d'un utilitaire en ligne de commande qui s'intègre avec les outils d'infrastructure as Code tels que Terraform, AWS CloudFormation, etc. Il fournit une analyse détaillée des coûts associés à ces ressources.

L'outil utilise les informations des APIs des fournisseurs de services cloud pour calculer les coûts des ressources.

Pourquoi self host Infracost ?​

Infracost offre trois options distinctes. Tout d'abord, il y a Infracost CI/CD, qui est entièrement gratuit, mais est limité à 1000 utilisations par mois. Ensuite, nous avons l'offre Infracost Cloud, qui propose un nombre illimité d'exécutions, mais à un coût de 50€ par utilisateur, ce qui peut représenter une dépense significative. Enfin, la troisième option consiste à self host Infracost, où les seuls frais à prendre en compte sont ceux associés à l'infrastructure sur laquelle il est déployé, tels que les coûts de la Web Application, de la base de données, etc. (github de l'API).

Qu'est-ce que le plugin Dependency-Check de SonarQube ?​

Le plugin Dependency-Check de Sonarqube (github) permet de détecter les vulnérabilités des dépendances utilisées dans le code source. Il est basé sur le projet OWASP Dependency-Check et utilise les bases de données de vulnérabilités de NVD et RetireJS. Grâce à ce plugin, il est possible d'identifier rapidement les vulnérabilités potentielles et donc de les corriger avant qu'elles ne soient exploitées par des attaquants. Dans cet article nous allons voir comment utiliser ce plugin avec une base de données selfhosted sur Azure mais nous partons du principe que vous avez déjà un Sonarqube fonctionnel. Si ce n'est pas le cas, vous pouvez vous référer à la documentation officielle de Sonarqube ici.

Azure Static Web Apps est un service Azure d'hébergement d'applications Web intégrant nativement un système de CDN.

Son prix attractif (gratuit ou environ 9€ / mois dans sa version standard) et son efficacité en font une ressource intéressante pour la publication de sites web peu complexes, tels que des portfolios, des sites de documentation...

Dans cet article, nous allons voir ensemble comme configurer le Single Sign On (SSO) sur cette ressource avec une authentification via Azure Active Directory (désormais Microsoft Entra ID) pour interdire tout accès anonyme à celle-ci.

Nous verrons aussi comment utiliser ce même Azure Active Directory pour implémenter une couche d'autorisation selon les groupes de l'Azure Active Directory auquel chaque utilisateur appartient, pour filtrer le contenu visible par un utilisateur connecté selon des droits lui ayant été attribués.

Présentation​

Comment ajouter une couche d'authentification simple à un site web hébergé sur un S3/Cloudfront AWS ?

C'est ce que je vais vous montrer ici, afin de reproduire le comportement de ce que pourrais faire un htaccess/htpasswd sur Apache.

Nous verrons plusieurs méthodes, grâce à l'utilisation de lambda@edge ou de fonction Cloudfront, à la main et via terraform.

Présentation​

Vous souhaitez héberger un site statique mais n’avez pas envie de devoir gérer l’installation d’un serveur web et la configuration d’un apache/nginx/…, il existe aujourd’hui des alternatives, sans aucune configuration de machine, sans maintenance, supportant les pics de charge et très performant.

Je vous présente ici une solution reposant sur les services fournis par AWS, ainsi qu’une gestion du site au travers de Gitlab ou Azure Devops et d’un pipeline de CI/CD.