Dépannage de la sécurité Jenkins : Accès refusé et erreurs d'autorisation

Les problèmes d'accès à Jenkins sont stressants car ils surviennent souvent au moment où quelqu'un doit déployer, relancer une construction échouée ou corriger la production. L'erreur peut indiquer Accès refusé, Permission manquante, 403 Aucun crumb valide, anonymous is missing Overall/Read, ou simplement renvoyer un utilisateur à la page de connexion. Ces messages se ressemblent, mais ils pointent vers différentes parties de la sécurité de Jenkins.

Le moyen le plus rapide de résoudre les problèmes de sécurité Jenkins est de séparer trois questions : Jenkins a-t-il reconnu l'utilisateur, Jenkins a-t-il accordé la bonne permission, et la demande a-t-elle passé les protections de demande de Jenkins ? L'authentification, l'autorisation et la protection CSRF sont des couches distinctes. Les traiter comme un vague "problème de connexion" fait perdre du temps.

Comprendre les fondamentaux de la sécurité Jenkins

Avant de plonger dans le dépannage, il est crucial de saisir les concepts de base de la sécurité Jenkins : l'authentification et l'autorisation.

Authentification vs Autorisation

• Authentification : C'est le processus de vérification de l'identité d'un utilisateur. Il répond à la question : "Qui êtes-vous ?" Lorsque vous vous connectez avec un nom d'utilisateur et un mot de passe, Jenkins vous authentifie par rapport à un domaine de sécurité.
• Autorisation : C'est le processus de détermination de ce qu'un utilisateur authentifié est autorisé à faire. Il répond à la question : "Que pouvez-vous faire ici ?" Une fois que Jenkins sait qui vous êtes, il vérifie vos permissions par rapport à sa stratégie d'autorisation pour décider si vous pouvez voir un travail, configurer un système ou lancer une construction.

Domaines de sécurité Jenkins (Authentification)

Un domaine de sécurité définit comment Jenkins authentifie les utilisateurs. Les options courantes incluent :

• Propre base de données d'utilisateurs de Jenkins : Les utilisateurs sont créés et gérés directement dans Jenkins.
• LDAP : S'intègre à un serveur LDAP existant (par exemple, Active Directory) pour authentifier les utilisateurs.
• Base de données d'utilisateurs/groupes Unix : Authentifie par rapport aux comptes d'utilisateurs du système d'exploitation sous-jacent.
• SAML / OAuth : S'intègre à des fournisseurs d'identité pour l'authentification unique.

Stratégies d'autorisation Jenkins

Une stratégie d'autorisation définit ce que les utilisateurs authentifiés peuvent faire. Les stratégies clés incluent :

• Les utilisateurs connectés peuvent tout faire : Simple, mais généralement trop large pour la production. Toute personne capable de se connecter a un pouvoir de type administrateur.
• Mode hérité : Conservé pour la compatibilité avec les anciennes installations. À éviter pour les systèmes de production.
• Sécurité basée sur une matrice : Permet un contrôle granulaire des permissions pour des utilisateurs/groupes individuels dans des contextes globaux et spécifiques au projet.
• Stratégie d'autorisation matricielle basée sur le projet : Une extension de la sécurité basée sur une matrice, permettant aux permissions spécifiques au projet de remplacer les paramètres globaux.
• Plugin de stratégie basée sur les rôles : Un plugin populaire qui simplifie la gestion des permissions en assignant les utilisateurs à des rôles, et les rôles à des permissions spécifiques (niveau global, dossier ou projet).

Scénarios courants menant à des erreurs 'Accès refusé'

Les erreurs 'Accès refusé' ou d'autorisation similaires résultent généralement de l'une des situations suivantes :

1. Identifiants incorrects : Nom d'utilisateur ou mot de passe simplement mal saisi.
2. Utilisateur introuvable : L'utilisateur tentant de se connecter n'existe pas dans le domaine de sécurité configuré.
3. Permissions insuffisantes : L'utilisateur est authentifié mais ne dispose pas de l'autorisation nécessaire pour effectuer l'action demandée (par exemple, voir un travail, configurer les paramètres système).
4. Problèmes de configuration du domaine de sécurité : Problèmes de connexion à une source d'authentification externe (par exemple, serveur LDAP hors service, DN de liaison incorrect).
5. Protection CSRF : La protection intégrée de Jenkins contre la falsification de requête intersite bloquant les requêtes programmatiques légitimes (par exemple, à partir de scripts ou d'outils externes).
6. Conflits de plugins ou mauvaise configuration : Un plugin lié à la sécurité (par exemple, stratégie basée sur les rôles) est mal configuré ou en conflit avec un autre plugin.
7. Problèmes de mise à niveau de Jenkins : Les paramètres de sécurité nécessitent parfois des ajustements après une mise à niveau majeure de Jenkins.

Dépannage des erreurs 'Accès refusé' et d'autorisation

Parcourons une approche systématique pour diagnostiquer et résoudre ces problèmes.

Étape 1 : Vérifier l'authentification (L'utilisateur est-il connu ?)

• Vérifier les identifiants : Assurez-vous que le nom d'utilisateur et le mot de passe sont corrects. Aussi simple que cela puisse paraître, c'est souvent le coupable.

• Tester avec un compte connu valide : Si vous avez un compte administrateur, essayez de vous connecter avec. Si le compte administrateur fonctionne, le problème vient probablement de l'authentification ou de l'autorisation de l'utilisateur spécifique. Si même le compte administrateur échoue, cela indique un problème plus large de domaine de sécurité.

• Examiner la configuration du domaine de sécurité : Accédez à Gérer Jenkins > Configurer la sécurité globale.

  • Propre base de données d'utilisateurs de Jenkins : Vérifiez si l'utilisateur existe sous Gérer Jenkins > Gérer les utilisateurs.
  • LDAP : Vérifiez l'URL du serveur LDAP, le DN du gestionnaire, le mot de passe du gestionnaire et la base de recherche d'utilisateurs. Assurez-vous que le serveur Jenkins peut atteindre le serveur LDAP (vérifiez la connectivité réseau). Vérifiez le bouton Tester les paramètres LDAP s'il est disponible.

  # Exemple : Tester la connectivité LDAP depuis le serveur Jenkins (remplacez par votre serveur LDAP/port)
  nc -vz ldap.example.com 389
  

Étape 2 : Vérifier la configuration de l'autorisation (Que peut faire l'utilisateur ?)

Une fois qu'un utilisateur est authentifié, l'étape suivante consiste à s'assurer qu'il dispose des permissions correctes.

• Identifier la stratégie d'autorisation active : Allez dans Gérer Jenkins > Configurer la sécurité globale et notez la stratégie d'autorisation sélectionnée.

• Sécurité basée sur une matrice :

  • Vérifiez la matrice des permissions globales sur la page Configurer la sécurité globale. Assurez-vous que l'utilisateur ou un groupe auquel il appartient dispose des permissions globales nécessaires (par exemple, Overall/Read, Job/Read).
  • Si l'autorisation matricielle basée sur le projet est activée, vérifiez les configurations de travail individuelles pour les remplacements. Un utilisateur peut avoir un Read global mais être explicitement refusé sur un projet spécifique.

• Plugin de stratégie basée sur les rôles :

  • Allez dans Gérer Jenkins > Gérer et attribuer les rôles (ou similaire, selon la version du plugin).
  • Vérifiez que les rôles sont définis avec des permissions appropriées (par exemple, rôles globaux, rôles de projet, rôles de dossier).
  • Assurez-vous que l'utilisateur est attribué aux rôles corrects.

• Astuce : Utilisez le lien "Qui suis-je ?" : Après vous être connecté (même avec un accès limité), cliquez sur le nom d'utilisateur dans le coin supérieur droit, puis "Qui suis-je ?". Cette page répertorie vos informations utilisateur et permissions actuelles, ce qui est inestimable pour le débogage.

Étape 3 : Examiner les journaux système de Jenkins

Les journaux Jenkins sont vos meilleurs amis pour obtenir des informations détaillées sur ce qui se passe en interne.

• Emplacement : Les journaux Jenkins se trouvent généralement dans $JENKINS_HOME/logs/jenkins.log. Vous pouvez également les visualiser via Gérer Jenkins > Journal système (si vous en avez la permission).

• Mots-clés à rechercher : Recherchez Accès refusé, authentification échouée, échec d'autorisation, permission refusée, SecurityFilter, AuthenticationManager, AuthorizationStrategy.

  # Exemple : rechercher dans les journaux Jenkins récents des termes de sécurité courants
  grep -Ei 'access denied|authentication|authorization|permission|crumb|csrf' "$JENKINS_HOME/logs/jenkins.log"
  

Lire l'erreur avant de modifier les paramètres

Le texte exact compte. anonymous is missing the Overall/Read permission signifie généralement que Jenkins n'a pas associé la demande à un utilisateur connecté. Cela peut se produire lorsqu'une session de navigateur a expiré, qu'un proxy inverse a supprimé des cookies, qu'un jeton API n'a pas été envoyé ou qu'un script a utilisé la mauvaise méthode d'authentification. Accorder plus de permissions à l'utilisateur n'aidera pas si Jenkins voit la demande comme anonyme.

user is missing Job/Build signifie que l'authentification a fonctionné, mais que l'autorisation a échoué. Dans ce cas, examinez la stratégie d'autorisation, les permissions de dossier, les paramètres matriciels du projet et les attributions de rôles. Pour les configurations Jenkins basées sur des dossiers, vérifiez d'abord le dossier. Un utilisateur peut avoir un accès en lecture global et manquer encore de permission dans un dossier.

No valid crumb was included in the request pointe vers la protection CSRF. C'est courant avec les scripts qui POSTent vers Jenkins en utilisant uniquement un nom d'utilisateur et un mot de passe. L'automatisation moderne devrait normalement utiliser un jeton API et soit récupérer un crumb depuis /crumbIssuer/api/json, soit utiliser un client/bibliothèque qui gère correctement les crumbs. Ne désactivez pas la protection CSRF juste pour faire fonctionner un script.

Accès refusé après une mise à niveau de plugin signifie souvent que le plugin a commencé à vérifier une permission plus spécifique qu'avant, ou que le lien UI a été déplacé dans une page protégée par une permission différente. Consultez le journal des modifications du plugin si le moment coïncide avec une mise à niveau. Si le problème a commencé après être passé de la sécurité matricielle à la sécurité basée sur les rôles, comparez les anciennes permissions aux nouveaux rôles un par un au lieu de supposer que les noms de rôles signifient la même chose.

Un ordre de dépannage sûr

Commencez par une connexion normale via navigateur. Utilisez une fenêtre privée pour que les anciens cookies ne perturbent pas le test. Si l'utilisateur ne peut pas se connecter, concentrez-vous sur le domaine de sécurité : base de données d'utilisateurs Jenkins locale, LDAP, Active Directory, SAML, OAuth, ou tout autre fournisseur configuré. Vérifiez si le format du nom d'utilisateur a changé. Certains fournisseurs d'identité envoient jane, d'autres envoient [email protected], et d'autres envoient un ID stable qui ne ressemble pas au nom d'utilisateur que les gens tapent.

Si la connexion fonctionne, ouvrez le profil de l'utilisateur et la page "Qui suis-je ?" si disponible. Confirmez l'ID utilisateur et les noms de groupe que Jenkins voit. C'est particulièrement utile avec LDAP et SSO, où l'appartenance à un groupe peut ne pas correspondre à ce que l'équipe d'identité attend. Un mappage de groupe manquant peut supprimer les permissions de nombreux utilisateurs à la fois.

Ensuite, testez avec un compte administrateur connu. Si l'administrateur peut effectuer l'action, l'instance est probablement saine et l'utilisateur concerné manque de permission. Si l'administrateur échoue également, recherchez un problème de configuration plus large, une défaillance de plugin, un problème de proxy inverse ou un comportement de crumb/session cassé.

Ensuite, vérifiez le plus petit objet affecté. Si l'utilisateur ne peut pas construire un travail, ne commencez pas par modifier la sécurité globale. Vérifiez ce travail, son dossier, les permissions héritées, le modèle de rôle et les entrées matricielles basées sur le projet. Un modèle de rôle comme team-a/.* ne correspondra pas à un dossier renommé tel que Team-A/service-api si l'expression régulière est sensible à la casse ou écrite de manière trop étroite.

Jetons API, Crumbs et échecs d'automatisation

De nombreux incidents de sécurité Jenkins ne sont pas des problèmes de connexion humaine. Ce sont des scripts qui fonctionnaient auparavant et qui échouent maintenant. La première chose à vérifier est de savoir si le script utilise un jeton API plutôt qu'un vrai mot de passe. Les jetons API sont plus faciles à faire tourner et plus sûrs à étendre opérationnellement.

Une demande simple pourrait ressembler à ceci :

curl -u "deploy-bot:${JENKINS_TOKEN}" \
  "https://jenkins.example.com/job/service-api/build?token=unused"

Pour les demandes POST qui nécessitent un crumb, récupérez-le d'abord :

CRUMB=$(curl -s -u "deploy-bot:${JENKINS_TOKEN}" \
  "https://jenkins.example.com/crumbIssuer/api/json" |
  jq -r '.crumbRequestField + ":" + .crumb')

curl -X POST -u "deploy-bot:${JENKINS_TOKEN}" \
  -H "$CRUMB" \
  "https://jenkins.example.com/job/service-api/build"

Certaines configurations Jenkins exemptent les demandes authentifiées par jeton API des vérifications de crumb, tandis que d'autres exigent toujours des crumbs selon la version et les plugins. Testez sur votre instance au lieu de copier des hypothèses d'un environnement différent.

Pour les comptes de service, accordez uniquement les permissions dont l'automatisation a besoin. Un déclencheur de déploiement peut nécessiter Job/Build sur un dossier. Il n'a probablement pas besoin de Overall/Administer. Si le même jeton est utilisé par dix scripts non liés, divisez-le en utilisateurs de service distincts afin de pouvoir faire tourner ou désactiver l'un sans tout casser.

Problèmes de proxy inverse qui ressemblent à des problèmes de sécurité Jenkins

Si Jenkins se trouve derrière Nginx, Apache, un équilibreur de charge ou un contrôleur d'entrée, les erreurs de session et de crumb peuvent provenir de la couche proxy. Vérifiez que Jenkins reçoit l'URL externe, le schéma, l'hôte et les en-têtes corrects. Un symptôme courant est que la connexion fonctionne pour une page et échoue sur la suivante car les cookies sont limités au mauvais hôte ou Jenkins pense que la demande est HTTP alors que le navigateur utilise HTTPS.

Examinez URL Jenkins sous Gérer Jenkins > Système. Elle doit correspondre à l'URL que les utilisateurs ouvrent réellement. Pour les proxys, assurez-vous que les en-têtes tels que X-Forwarded-Proto et X-Forwarded-Host sont transmis correctement. Si des connexions WebSocket ou d'agent sont impliquées, vérifiez ces chemins séparément de la connexion du navigateur.

Les contrôleurs à équilibrage de charge sont un signe d'avertissement spécial. Un contrôleur Jenkins normal est avec état. Ne mettez pas plusieurs contrôleurs Jenkins indépendants derrière une seule URL et attendez-vous à ce que les sessions, l'état de la file d'attente et l'état du travail se comportent comme une application Web sans état. La haute disponibilité pour Jenkins nécessite un produit ou une architecture conçue pour cela, pas un équilibreur de charge round-robin générique.

Accès d'urgence sans aggraver l'instance

Si tout le monde est verrouillé, faites une pause avant de modifier les fichiers. Faites d'abord une sauvegarde ou un instantané de $JENKINS_HOME si possible. La configuration de sécurité réside dans des fichiers XML, et une modification précipitée peut rendre la récupération plus difficile.

Le chemin de secours habituel consiste à désactiver temporairement la sécurité dans config.xml, redémarrer Jenkins, retrouver l'accès, corriger les paramètres de sécurité depuis l'interface utilisateur, puis réactiver immédiatement la sécurité. Cela doit être traité comme une action d'urgence, pas comme une solution de contournement de routine. Restreignez l'accès réseau pendant que la sécurité est désactivée. Enregistrez ce qui a changé. Faites tourner les identifiants qui ont pu être exposés pendant l'incident.

Si vous utilisez la configuration comme code, ne corrigez pas l'interface utilisateur et n'oubliez pas le fichier source. Le prochain rechargement pourrait annuler la correction. Mettez à jour le YAML CasC, examinez-le et appliquez-le via le processus normal une fois l'accès rétabli.

Prévenir les verrouillages répétés

Conservez au moins deux comptes ou groupes d'administrateurs humains, de préférence soutenus par différents chemins de récupération. Si tous les administrateurs dépendent d'un seul groupe SSO et que ce mappage de groupe se brise, personne ne peut réparer Jenkins depuis l'interface utilisateur.

Documentez votre modèle d'autorisation en langage clair. "Les développeurs peuvent lire et construire des travaux dans leur dossier. Les ingénieurs de publication peuvent configurer des travaux de déploiement. Les administrateurs de plateforme administrent Jenkins." C'est plus utile qu'une capture d'écran d'une matrice avec des centaines de cases à cocher.

Examinez les permissions après les déplacements de dossiers, les modifications de plugins, les modifications SSO et les mises à niveau de Jenkins. Les problèmes de sécurité apparaissent souvent après un renommage anodin ou un nettoyage du fournisseur d'identité.

Enfin, testez les jetons de compte de service avant de supprimer les anciens identifiants. Un court script d'audit qui vérifie les comptes d'automatisation clés peut sauver une fenêtre de déploiement. Le dépannage de sécurité est beaucoup plus facile lorsque vous savez si la panne s'est produite au niveau de la connexion, de l'évaluation des permissions, de la protection des demandes ou du proxy devant Jenkins.