GUIDE TECHNIQUE · RUNDECK
Rundeck : ACL et Key Storage pour le RUN
Sécuriser Rundeck avec des ACL minimales, un Key Storage séparé par projet et des comptes d'exécution dédiés, sans faire apparaître de secrets dans les logs.
L’ESSENTIEL EN BREF
Les étapes clés
Ce guide présente 4 étapes, de « Établir la matrice d'autorisations » à « Tester les refus ».
Avant de commencer : Projet de recette et utilisateur de test sans droits administrateur globaux.
01 · CADRAGE
Périmètre et résultat visé
Résultat attendu : Les opérateurs n'ont pas de droits de modification inutiles.
Public concerné : Administrateurs Rundeck, responsables IAM et équipes d'exploitation
Rundeck Community ou édition commerciale ; la portée de Key Storage et le modèle ACL dépendent de la configuration d'instance.
Contrôlez les versions, les droits et les options disponibles dans votre environnement avant de suivre la procédure.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Projet de recette et utilisateur de test sans droits administrateur globaux.
- Connaissance des rôles, groupes, ACL existantes et service de stockage des secrets.
- Matrice explicite : lecteur, exécuteur, administrateur de projet.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Suivez les étapes dans l’ordre et contrôlez chaque résultat avant de poursuivre. Renseignez les paramètres adaptés à votre environnement.
ÉTAPE 1 / 4
Établir la matrice d'autorisations
La séparation lecture, exécution et modification limite les erreurs d'exploitation.
- Identifier les groupes et les projets auxquels ils doivent accéder.
- Prévoir l'accès application au projet et les droits de job et node au niveau projet.
# Exemple de matrice à valider :
# observateur : view/read
# opérateur : view/read/run
# éditeur : create/update après habilitationÀ vérifier : Les rôles nécessaires sont documentés sans wildcard global.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 2 / 4
Définir une ACL restrictive
Les permissions sont explicites par ressource et environnement.
- Créer une politique ACL pour un groupe pilote et un projet de recette.
- Commencer par lecture et exécution sur un sous-ensemble de jobs.
description: Operateurs du projet recette
context:
project: recette
for:
job:
- match: { name: 'verifier-.*' }
allow: [read, view, run]
by:
group: operateurs-recetteÀ vérifier : Le groupe n'accède qu'aux jobs de recette prévus.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 3 / 4
Isoler le Key Storage
La lecture d'un secret est un privilège distinct de l'exécution d'un job.
- Choisir un chemin de clés propre au projet et importer uniquement le secret de recette.
- Associer au job une référence de stockage plutôt que recopier le secret dans un script.
# Convention indicative de stockage :
keys/project/recette/ssh-runnerÀ vérifier : La clé n'apparaît ni dans l'export du job ni dans ses logs.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 4 / 4
Tester les refus
Une ACL n'est vérifiée qu'en testant ce qui doit être interdit.
- Avec un compte non admin, lancer un job autorisé puis tenter d'accéder à un job d'un autre projet.
- Contrôler l'accès au Key Storage, les logs et les événements d'audit.
# Cas de recette :
# run job recette => autorisé
# lire secret autre projet => refuséÀ vérifier : Les essais montrent des autorisations minimales et des refus efficaces.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
RÉFÉRENCES TECHNIQUES
Documentation officielle
Retrouvez les prérequis, les fonctionnalités et les versions prises en charge par Rundeck. Vérifiez les commandes sur un environnement de test avant leur utilisation en production.
05 · RECETTE
Comment vérifier que tout fonctionne ?
Les opérateurs n'ont pas de droits de modification inutiles.
Les clés sont confinées au Key Storage du projet.
Un compte de test ne peut pas accéder à une ressource non autorisée.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Job invisible
Cause probable : Accès application au projet absent
Que faire : Vérifier les deux contextes ACL, application et projet.
Exécution refusée
Cause probable : Droit run manquant sur job ou node
Que faire : Inspecter les autorisations réellement requises par le workflow.
Clé introuvable
Cause probable : Chemin ou permission Key Storage incorrect
Que faire : Vérifier le chemin stocké et le contexte ACL effectif.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Une ACL projet suffit-elle ?
Pas toujours : un utilisateur doit aussi pouvoir voir le projet dans le contexte application.
Où stocker une clé SSH ?
Dans Key Storage ou un gestionnaire de secrets intégrable, jamais dans les options non sécurisées.
Quelle différence entre voir et exécuter un job ?
read/view permet la consultation ; run autorise son lancement dans le périmètre visé.
AUTRES TECHNOLOGIES
Guides complémentaires
VOTRE ENVIRONNEMENT
Besoin d’aller plus loin sur votre environnement ?
Automatisation, sécurité et exploitation : échangeons sur vos pratiques Rundeck.
Échanger avec ADN Consulting