3 countries, site admins, many customers, jenkins security?
Daniel Mueller
Hi,
We are a software house with many different customers based in Europe and we recently opened offices in USA and China. Currently we run a single Jenkins master and our contracts require us to at least have one dedicated slave per customer account (but many projects of same customer on same slave). However, since we expanded into other regions, legal department requires us to rethink our Jenkins setup because legally it is not allowed that somone from the US team is allowed to checkout a project that is Europe based unless it’s a global project. Job security configuration enables us to show members of each region to see only the Jobs that they are allowed to see. But our credentials are currently held in the Jenkins global store so a USA DevOp could still create a Job and select the credentials from a EUROPE Project and check out the source code, or use Maven credentials to access the projects Maven repository. The goal is to find a solution to prevent such access violations.
I could think of 3 scenarios (and combinations of those):
Scenario A:
Keep one master, use folders plugin and setup 4 folders (CHINA, USA, EUROPE and GLOBAL). Use role strategy plugin to secure those folders. Add credentials to the folders store.
Config file plugin sets up config files (e.g. Maven settings) ONLY global. So users from all regions can select all config files in a job and that would enable every user to download from all maven repositories, that’s a blocking issue.
· Pros
o Maintenance is low
o Very flexible security model possible
· Cons
o The config file plugin is global only, all Artifacts could be accessed from every region (blocker unless we find a solution!!!)
o In its current version, folders plugin does not add a credentials store (https://issues.jenkins-ci.org/browse/JENKINS-39302)
Scenario B:
One Jenkins master for every region.
· Pros
o Security is ensured
· Cons
o Not very flexible
o Higher maintenance
Scenario C:
One Jenkins master for every customer account. Basically means every slave becomes a master
· Pro
o Security model is very flexible
o Individual setups
o Lowest impact on system faults
· Cons
o High maintenance
I would prefer Scenario A, but the config file issue is a nogo for the legal department. Is the a way to get secured Maven repositories into a build. We use LDAP logins on developer machines, Jenkins log in to these maven repos with a technical user and the password should not be stored in plain text in Git.
Are there other options I forgot?
Is there a solution to the config file security problem?
How do you setup your Jenkins with similar restriction?
Every help is appreciated, thanks in advance,
Daniel
Daniel Beck
> On 08.11.2016, at 09:25, Daniel Mueller <daniel....@osthus.com> wrote:
>
> o The config file plugin is global only, all Artifacts could be accessed from every region (blocker unless we find a solution!!!)
>
You can monitor it at https://github.com/jenkinsci/config-file-provider-plugin/pull/18