HackTricks CloudOpenShift - Jenkins
Reading time: 2 minutes
L'auteur original de cette page est Fares
Cette page donne quelques indications sur la façon dont vous pouvez attaquer une instance Jenkins fonctionnant 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 montrée. Pour plus d'informations sur l'attaque de Jenkins, vous pouvez consulter cette page.
Prérequis
1a. Accès utilisateur dans une instance Jenkins OU 1b. Accès utilisateur avec autorisation d'écriture à un dépôt SCM où une construction automatisée est déclenchée après un push/merge.
Comment ça fonctionne
Fondamentalement, presque tout ce qui se passe en arrière-plan fonctionne de la même manière qu'une instance Jenkins régulière fonctionnant dans une VM. La principale différence est l'architecture globale et la façon dont les constructions sont gérées à 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 juste un pod régulier fonctionnant dans un namespace (qui pourrait être différent de celui où les travailleurs fonctionnent). 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 un accès UI à Jenkins
Une façon très facile et pratique est d'utiliser la fonctionnalité Replay 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 devez être furtif, vous pouvez supprimer vos constructions déclenchées si vous avez suffisamment de permissions.
- Vous avez un accès en écriture au SCM et des constructions automatisées sont configurées via webhook
Vous pouvez simplement modifier un script de construction (tel que Jenkinsfile), valider et pousser (éventuellement créer une PR si les constructions ne sont déclenchées que lors des fusions de PR). Gardez à l'esprit que ce chemin est très bruyant et nécessite des privilèges élevés pour nettoyer vos traces.