Utilisation du module Ansible URI avec des jetons SonarQube

RedHat Ansible est un outil de gestion de configuration très flexible fourni avec une variété de modules intégrés. L’un de ces modules, ansible.builtin.uriest fourni comme une alternative à l’utilisation des commandes « curl » via le ansible.builtin.shell ou ansible.builtin.command modules. Cependant, la documentation du module ne fournit pas d’exemple spécifique sur la façon d’utiliser le module URI lors de l’utilisation de l’authentification basée sur les jetons. Ce billet de blog montre des exemples de la façon dont cela peut être fait en utilisant Appels API SonarQube.

Exemple #1 : Authentification par nom d’utilisateur et mot de passe

Lors de l’utilisation du module URI pour les appels d’API SonarQube avec authentification par nom d’utilisateur et mot de passe (qui peut être récupéré à partir d’Ansible Vault si vous le souhaitez), il est nécessaire de fournir les champs « utilisateur : » et « mot de passe : » ainsi que le champ « force_basic_auth ». . Dans cet exemple, nous allons générer un nouveau jeton pour l’utilisateur par défaut fourni en utilisant un nom de jeton unique :

# generate a new user token for this session using the project_key
- name: Generate a SonarQube Session Token
ansible.builtin.uri:
url: http://{{sonar_url}}:9000/api/user_tokens/generate
user: "{{sonar_user_name}}"
password: "{{sonar_user_pwd}}"
method: POST
force_basic_auth: yes
body_format: form-urlencoded
body:
name: "{{project_key}}"
register: get_sonor_output
no_log: true
- set_fact: sonar_admin_token="{{ get_sonor_output.json.token }}"


Le résultat de retour contiendra le jeton nouvellement généré sous la section json{} qui peut être stocké dans une variable à l’aide de ‘set_fact’ :

"json": {
            "createdAt": "2022-05-31T20:34:12+0000",
            "login": "admin",
            "name": "costar125",
            "token": "4f12fd916c878f936e9bf3f04fc460ee4b225be3"
        },

En stockant ce jeton dans une variable « fait », il peut être utilisé dans les appels API ultérieurs.

Exemple #2 : Authentification basée sur des jetons – création d’un projet

Pour utiliser un jeton dérivé de SonarQube, l’API attend le jeton dans le champ « utilisateur : ». Cependant, le champ « mot de passe : » doit également être renseigné et laissé comme « nul ». Cela force le module URI à générer un appel d’API sans mot de passe que SonarQube attend. Dans cet exemple, nous utilisons le jeton généré ci-dessus pour authentifier l’appel d’API afin de créer un nouveau projet SonarQube. Notez que si le projet existe déjà, il générera une erreur. Cela peut être évité par un appel d’API de tâche précédent pour obtenir tous les projets (à l’aide de la clé de projet unique), puis valider à l’aide d’une clause ‘quand’ que le nouveau projet n’est pas déjà présent

Exemple #3 : Authentification basée sur un jeton – révocation du jeton

Enfin, si le jeton ne doit plus être utilisé, il peut être révoqué de la même manière qu’il a été créé :

# revoke the session token
- name: Revoke a SonarQube Session Token
ansible.builtin.uri:
url: http://{{sonar_url}}:9000/api/user_tokens/revoke
user: "{{sonar_admin_token}}"
password: ""
method: POST
force_basic_auth: yes
body_format: form-urlencoded
body:
name: "{{project_key}}"
status_code: [200, 204]
register: get_sonor_output
no_log: true


Dans cet article de blog, nous avons exploré comment le module Ansible URI peut être utilisé pour a) générer un nouveau jeton de sécurité, b) transmettre un jeton de sécurité aux API SonarQube pour créer un nouveau projet (s’il n’est pas déjà présent), et c) pour révoquer le jeton nouvellement créé à la fin de la session Ansible. Dans ces exemples, l’appel de l’API SonarQube attendait le jeton dans le champ ‘user:’ avec un mot de passe nul. D’autres appels d’API peuvent nécessiter que le champ « mot de passe : » contienne le jeton et ignore le champ utilisateur. Vérifiez attentivement votre documentation pour voir quelle approche est utilisée pour les appels d’API spécifiques.

A propos de l’auteur

Ben Lieberman est actuellement directeur du groupe de prestation DevOps de Perficient Inc.. Le Dr Lieberman a plus de vingt-cinq ans d’expérience dans le développement de logiciels et de systèmes dans un large éventail d’industries, notamment la finance, le gouvernement, les télécommunications, les sciences de la vie, les services de voyage et les systèmes de lancement spatial. Il possède une grande expérience sur plusieurs sujets de développement de logiciels, notamment l’analyse des exigences, l’analyse et la conception de systèmes, le développement de systèmes sécurisés, la gestion de la configuration et le déploiement automatisé (alias DevSecOps). Il possède également une expérience de développement directe dans plusieurs langages, notamment les langages de codage Java, C #, C ++ et Salesforce (APEX), et travaille directement avec les équipes de développement sur les pratiques de livraison agiles. Le Dr Lieberman est un écrivain professionnel accompli avec un livre (« The Art of Software Modeling », Auerbach Publishing) et plus de trois douzaines d’articles informatiques professionnels à son actif. Le Dr Lieberman est titulaire d’un doctorat en biophysique et génétique de l’Université du Colorado, Anschutz Medical Center, Denver, Colorado.

Plus de cet auteur