Как ограничить доступ к файловой системе в сборках Atlassian Bamboo?

У нас работает Atlassian Bamboo на Ubuntu. Когда разработчик настраивает сборку, он может запускать задачи сценария оболочки. Это полезно для запуска (пользовательских) команд на базе кода, которую вы строите.

Однако выполняемые сценарии могут также обращаться к файловой системе вне своего каталога заданий в рабочем каталоге Bamboo ( <Bamboo-home-dir>/xml-data/build-dir/JOB_KEY). Так JOB_A можно также получить доступ к файлам на JOB_B: cd ../JOB_B.

Есть ли возможность ограничить этот доступ?

PS Мне известно о том, что сборки выполняются агентами (локальными или удаленными) в Bamboo, и вы можете создавать разные проекты разными агентами. Однако, если два проекта создаются одним и тем же агентом, они могут получить доступ к файлам друг друга.

В настоящее время нет возможности ограничить потенциальные взаимодействия заданий, которые могут выполняться на одном агенте, друг с другом. Существует множество запросов функций, требующих такого рода детализации, но если я правильно понимаю ваш вопрос, наиболее подходящим будет запрос BAM-2504 Jira Ticket.

Это огромный пробел в линейке продуктов, единственное решение, которое я нашел, похоже на то, что предлагается в запросе, связанном выше, по сути, ваш бамбуковый процесс должен был бы запускаться с достаточными привилегиями, чтобы выдавать себя за группу пользователей, которые представляют проекты, которые Вы хотели бы держать отдельно.

Если у вас есть такой механизм, вам нужно просто попытаться обеспечить, чтобы все планы выполнялись как одна из безличных учетных записей, в зависимости, например, от проекта или создателя и т. Д.

Проблематично то, как в настоящее время существуют средства управления доступом, это будет означать, что немногие основные администраторы должны будут настроить все планы, чтобы они могли быть уверены в разделении необходимых разрешений, а не позволять неадминистративным пользователям редактировать и создавать свои собственные планы.

Если такого рода подход неосуществим, что невозможно, если вы попадаете в диапазон «много сотен пользователей», то единственное, что вы можете сделать, чтобы попытаться остановить взаимодействие между сборочными заданиями, это реализовать очень слабый контроль, который дает вам бамбук.

Я попробовал два подхода к этому:

1. Удалите или покалечите (удалите все возможности) ваших локальных агентов и для каждого отдельного проекта / команды / чего бы то ни было на досках вашего бамбукового экземпляра, вам нужно заставить их создать сервер сборки BYO. В большинстве случаев я принимал участие в том, что стоимость агента совершенно тривиальна по сравнению со стоимостью потенциальной утечки данных или злонамеренного взаимодействия с планом.
2. Убедитесь, что проекты, которые имеют или думают, что имеют конфиденциальные данные, включенные в их планы, всегда дезинфицируют свою среду после создания. Это снимает бремя с команды, управляющей инструментами, и над проектами, которые пишут свои планы, и вынуждает их оборонительно очищать любую информацию, которую они не хотят, потенциально доступны для других.

Ни одно из решений даже близко не идеально, но, насколько мне известно, речь идет о таком большом разделении, какое вы можете обеспечить, если у вас есть общий экземпляр бамбука.