Jak ograniczyć dostęp do systemu plików w kompilacjach Atlassian Bamboo?

Mamy Atlassian Bamboo na Ubuntu. Gdy programista konfiguruje kompilację, wówczas ma możliwość uruchamiania zadań skryptu powłoki. Jest to przydatne do uruchamiania (niestandardowych) poleceń w budowanej bazie kodu.

Jednak uruchamiane skrypty mogą również uzyskiwać dostęp do systemu plików poza katalogiem zadań w katalogu roboczym Bamboo ( <Bamboo-home-dir>/xml-data/build-dir/JOB_KEY). Więc JOB_A może również dostęp do plików z JOB_B: cd ../JOB_B.

Czy istnieje możliwość ograniczenia tego dostępu?

PS Zdaję sobie sprawę z tego, że kompilacje są uruchamiane przez (lokalnych lub zdalnych) agentów w Bamboo i możesz budować różne projekty przez różnych agentów. Jeśli jednak dwa projekty są budowane przez tego samego agenta, projekty mogą uzyskiwać dostęp do swoich plików.

Obecnie nie ma możliwości ograniczenia zadań potencjalnie działających na tym samym agencie przed potencjalną interakcją. Istnieje wiele próśb o nowe funkcje, które proszą o taki rodzaj szczegółowości, ale jeśli dobrze zrozumiem twoje pytanie, najbardziej odpowiednie byłoby jedno z nich : Bilet Jira BAM-2504

Jest to ogromna luka w linii produktów, jedyne znalezione przeze mnie rozwiązanie jest podobne do tego, które proponuje powyższe żądanie, w zasadzie proces bambusa musiałby działać z wystarczającymi uprawnieniami, aby podszyć się pod grupę użytkowników reprezentujących projekty, które chciałbyś zachować osobność.

Po wprowadzeniu tego rodzaju mechanizmu musisz po prostu wymusić, aby wszystkie plany działały jako jedno z personifikowanych kont, w zależności na przykład od projektu lub twórcy itp.

Problematycznie sposób, w jaki obecnie istnieją mechanizmy kontroli dostępu, oznaczałoby, że niewielu głównych administratorów musiałoby skonfigurować wszystkie plany, aby mieć pewność, że wymagane uprawnienia zostaną podzielone, zamiast pozwolić użytkownikom nie będącym administratorami edytować i tworzyć własnych planów.

Jeśli tego rodzaju podejście jest niewykonalne, co nie jest możliwe po wejściu w zakres „wielu setek użytkowników”, wówczas jedyną rzeczą, którą możesz naprawdę zrobić, aby powstrzymać interakcję między zadaniami budowania, jest wdrożenie bardzo słaba kontrola, którą daje bambus.

Wypróbowałem dwa podejścia do tego:

1. Usuń lub unieważnij (usuń wszystkie możliwości) swoich lokalnych agentów, a dla każdego innego projektu / zespołu / cokolwiek, co jest na desce do twojej instancji bambusowej, musisz zmusić ich do serwera budowania BYO. W większości przypadków, gdy byłem zaangażowany, koszt agenta jest całkowicie trywialny w porównaniu z kosztem potencjalnego wycieku danych lub interakcji ze szkodliwym planem.
2. Upewnij się, że projekty, które mają wrażliwe dane lub które myślą, że mają takie wrażliwe dane, zaangażowane w ich plany, zawsze dezynfekują swoje środowiska po ich zbudowaniu. To odciąża zespół administrujący narzędziami i spoczywa na projektach, które piszą swoje plany, i zmusza ich do defensywnego czyszczenia wszelkich informacji, które nie powinny być potencjalnie dostępne dla innych.

Żadne z tych rozwiązań nie jest nawet bliskie ideału, ale według mojej najlepszej wiedzy chodzi o tyle separacji, ile możesz wymusić, jeśli masz wspólną instancję bambusa.