OpenShift - Jenkins
L'auteur original de cette page est Fares
Cette page donne quelques indications sur la manière dont vous pouvez attaquer une instance Jenkins s'exécutant dans un cluster Openshift (ou Kubernetes)
Avertissement
Une instance Jenkins peut être déployée à la fois dans un cluster Openshift ou Kubernetes. Selon votre contexte, vous devrez peut-être adapter tout payload, yaml ou technique affiché. Pour plus d'informations sur l'attaque de Jenkins, vous pouvez consulter cette page
Prérequis
1a. Accès utilisateur à une instance Jenkins OU 1b. Accès utilisateur avec permission d'écriture à un dépôt SCM où une construction automatisée est déclenchée après un push/fusion
Comment ça marche
Fondamentalement, presque tout en coulisses fonctionne de la même manière qu'une instance Jenkins régulière s'exécutant dans une VM. La principale différence réside dans l'architecture globale et la gestion des constructions à l'intérieur d'un cluster Openshift (ou Kubernetes).
Constructions
Lorsqu'une construction est déclenchée, elle est d'abord gérée/orchestrée par le nœud maître Jenkins puis déléguée à un agent/esclave/travailleur. Dans ce contexte, le nœud maître est simplement un pod régulier s'exécutant dans un espace de noms (qui pourrait être différent de celui où les travailleurs s'exécutent). Il en va de même pour les travailleurs/esclaves, cependant ils sont détruits une fois la construction terminée tandis que le maître reste toujours actif. Votre construction est généralement exécutée à l'intérieur d'un pod, en utilisant un modèle de pod par défaut défini par les administrateurs Jenkins.
Déclenchement d'une construction
Vous avez plusieurs façons principales de déclencher une construction telles que :
Vous avez accès à l'interface utilisateur de Jenkins
Une manière très facile et pratique est d'utiliser la fonctionnalité de Rejouer d'une construction existante. Cela vous permet de rejouer une construction précédemment exécutée tout en vous permettant de mettre à jour le script groovy. Cela nécessite des privilèges sur un dossier Jenkins et un pipeline prédéfini. Si vous avez besoin d'être discret, vous pouvez supprimer vos constructions déclenchées si vous avez suffisamment de permissions.
Vous avez un accès en écriture au SCM et les constructions automatisées sont configurées via un webhook
Vous pouvez simplement modifier un script de construction (tel qu'un Jenkinsfile), valider et pousser (éventuellement créer une PR si les constructions ne sont déclenchées que sur les fusions de PR). Gardez à l'esprit que cette voie est très bruyante et nécessite des privilèges élevés pour effacer vos traces.
Remplacement du YAML du pod de construction Jenkins
Last updated