Comment restreindre l'accès au système de fichiers dans les builds Atlassian Bamboo?


12

Nous avons Atlassian Bamboo sous Ubuntu. Lorsqu'un développeur configure une build, il a la possibilité d'exécuter des tâches de script shell. Ceci est utile pour exécuter des commandes (personnalisées) sur la base de code que vous construisez.

Cependant, les scripts qui s'exécutent peuvent également accéder au système de fichiers en dehors de leur répertoire de travail dans le répertoire de travail Bamboo ( <Bamboo-home-dir>/xml-data/build-dir/JOB_KEY). Donc JOB_A pouvez également accéder aux fichiers de JOB_B: cd ../JOB_B.

Y a-t-il une possibilité de restreindre cet accès?

PS Je suis conscient du fait que les builds sont exécutés par des agents (locaux ou distants) dans Bamboo et vous pouvez créer différents projets par différents agents. Cependant, si deux projets sont créés par le même agent, les projets peuvent accéder aux fichiers de l'autre.

Réponses:


9

Il n’existe actuellement aucune possibilité de restreindre les travaux susceptibles d’exécuter sur le même agent d’interagir potentiellement les uns avec les autres. Il y a un tas de demandes de fonctionnalités demandant ce genre de granularité, mais si je comprends bien votre question, la demande la plus appropriée serait celle-ci BAM-2504 Jira Ticket

C'est une énorme lacune dans la gamme de produits, la seule solution que j'ai trouvée est similaire à celle proposée par la demande liée ci-dessus, essentiellement votre processus de bambou devrait fonctionner avec des privilèges suffisants pour usurper l'identité d'un ensemble d'utilisateurs qui représentent les projets qui vous souhaitez rester séparé.

Une fois que vous avez ce type de mécanisme en place, il vous suffit d'essayer de faire en sorte que tous les plans s'exécutent comme l'un des comptes imitables, en fonction par exemple du projet ou du créateur, etc.

De manière problématique, la façon dont les contrôles d'accès existent actuellement, cela signifierait que peu d'administrateurs principaux devraient configurer tous les plans afin qu'ils puissent être sûrs des autorisations requises divisées plutôt que de laisser les utilisateurs non administratifs modifier et créer leurs propres plans.

Si ce type d'approche n'est pas réalisable, ce qui n'est pas le cas une fois que vous entrez dans le type "plusieurs centaines d'utilisateurs", alors la seule chose que vous pouvez vraiment faire pour essayer d'empêcher les travaux de construction d'interagir les uns avec les autres est de mettre en œuvre le contrôles très faibles que le bambou vous donne.

J'ai essayé deux approches pour ce faire:

  1. Supprimez ou paralysez (supprimez toutes les capacités de) vos agents locaux et pour chaque projet / équipe / tout ce qui se trouve sur les cartes de votre instance de bambou, vous devez les forcer à BYO build server. Dans la plupart des cas, j'ai été impliqué dans le coût d'un agent est tout à fait trivial par rapport au coût d'une fuite de données potentielle ou d'interactions malveillantes avec un plan.
  2. Assurez-vous que les projets qui ont, ou qui pensent en avoir, des données sensibles impliquées dans leurs plans désinfectent toujours leur environnement après leur construction. Cela déplace le fardeau de l'équipe qui administre les outils sur les projets qui rédigent leurs plans et les oblige à nettoyer de manière défensive toute information dont ils ne veulent pas potentiellement être disponible pour les autres.

Aucune de ces solutions n'est même proche de la perfection, mais au meilleur de ma connaissance, cela représente autant de séparation que vous pouvez appliquer si vous avez une instance de bambou partagée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.