Stephen,
thanks for the suggestions. I'm sure that with the two methods you
described it's possible to divide roles into those who can control a docker
host, and those who can't, and the second method is even safe against
privilege escalation. The organization I work for is a Cloudbees customer,
but unfortunately both methods you suggested don't support use cases where
both groups in your "lock down" scenario must be allowed to configure
Workflow scripts with `docker.image().inside{}` (and that's what I have in
mind).
FYI: I did some tests with the "setuid docker proxy" method I proposed.
Writing a docker shim that filters commands and parameters to prevent
privilege escalation seems to be feasible (i.e. one that only passes on
commands, flags, and arguments in compliance with the intended use case in
Jenkins Workflow).
/Thomas
On Monday, January 11, 2016 at 11:34:34 PM UTC+1, Stephen Connolly wrote:
>
> You can use a feature such as
> http://documentation.cloudbees.com/docs/cje-user-guide/foldersplus-sect-controlledslaves.html
>
> so that only jobs in a specific folder can use the build slave... then you
> can use an authorization strategy (
> http://documentation.cloudbees.com/docs/cje-user-guide/rbac.html pairs
> well but there are others) so that only trusted users can configure jobs in
> that folder... yes there are still ways to hack around if you don't use
> script security or let untrusted users run jobs on the Jenkins master...
> but a locked down Jenkins is still possible...
>
> If you want something even more secure you can have multiple Jenkins
> instances connected together and trigger the jobs on the locked down ones
> from slightly lesser locked down ones:
> http://documentation.cloudbees.com/docs/cjoc-user-guide/cluster-triggers.html
>
> All the above is possible (i.e. I wrote a good chunk of that
> functionality) so even if you didn't want to purchase from CloudBees it is
> possible to implement the same in plugins (though the CJOC stuff would be a
> bigger chunk of work)
>
> On 11 January 2016 at 20:01, Thomas Goeppel <thomas....@gmail.com
> <javascript:>> wrote:
>
>> Stephen,
>>
>> thanks for your reply. You're right, nobody would run Jenkins as root in
>> a production environment, but through the Cloudbees Docker Workflow plugin
>> Jenkins is in control of the docker client, and hence it's root on some
>> machine (e.g. a build slave).
>>
>> I don't really understand what you mean with "running a build slave as
>> the trusted account". Maybe I'm missing something here, but from a security
>> point of view, as soon as untrusted users control a docker host on a build
>> slave (e.g. through Jenkins job definitions) that build slave is all but
>> trusted, and an untrusted machine has no place in a corporate network. If
>> one builds a firewall around an untrusted build slave as mitigation, I
>> would expect practical problems accessing SCM or artifact repositories
>> inside the corporate network from that slave.
>>
>> Calling the docker client through Jenkins can be considered safe if
>> Jenkins runs in a locked down environment (where only trusted users can
>> define jobs), or if the docker host (build slave) is short lived (e.g. an
>> ephemeral VM like Boot2Docker). Unfortunately, non of these options would
>> work for me.
>>
>> /Thomas
>>
>>
>> On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote:
>>>
>>> FYI you do not run *Jenkins* as root... rather you run a build slave as
>>> the trusted account and then you lock down access to that build slave...
>>> e.g. if that build slave deploys into production you can use it as a kind
>>> of bastion host whereby it is off-line until you want to deploy into
>>> production.
>>>
>>> On 10 January 2016 at 11:17, Thomas Goeppel <thomas....@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>>>>>
>>>>> > One option would be to write a shim for the docker command, that
>>>>> only
>>>>> > allows a subset of commands, and sanitizes the options and
>>>>> parameters.
>>>>>
>>>>> Even if you do that, the jenkins user, as part of the docker group,
>>>>> will
>>>>> still have direct access to the unix socket that the Docker daemon
>>>>> uses.
>>>>>
>>>>>
>>>> As is quite often the case with a CI server, you most likely need to
>>>>> either trust the users who can configure jobs (or edit Workflow
>>>>> scripts
>>>>> (if in source control)), or lock down the Jenkins configuration to
>>>>> allow
>>>>> only specific users.
>>>>>
>>>>>
>>>>
>>>>> The Docker security guide also says "only trusted users should be
>>>>> allowed to control your Docker daemon":
>>>>> https://docs.docker.com/engine/articles/security/
>>>>>
>>>>> I feel that you're mixing up two areas of trust here, Jenkins (and CI
>>>> users), and Docker (and system administrators). In an organization of any
>>>> size or complexity, the roles allowed to control Jenkins won't be held by
>>>> the same people that have the roles with root access. Even if it were so,
>>>> just how much would one have to lock down a Jenkins production environment
>>>> to mitigate the risks associated with running Jenkins as root, i.e. user
>>>> "jenkins" in the group "docker"?
>>>>
>>>> We could give up on provisioning containerized toolchains through
>>>> Jenkins in a Non-Root-Jenkins production environment, but there is a lot
>>>> of
>>>> value in running and controlling Docker containers through Jenkins.
>>>> Fortunately, full control of Docker isn't required for this use case:
>>>> Jesse
>>>> Glick demonstrated that nicely with the implementation of
>>>> docker.image().inside {} that passes reasonably safe parameters through
>>>> the
>>>> Docker CLI (e.g. -u non-root).
>>>>
>>>> Obviously, delegation of watching over safe use of the Docker CLI to
>>>> Jenkins isn't possible in any environment where we can't run Jenkins as
>>>> "root" ("docker"), and hence we need a trusted proxy. Technically that
>>>> proxy might run with "setuid docker" (and have access to the Unix socket),
>>>> or use a web service, but I think that the docker counterpart to a
>>>> "restricted
>>>> shell <https://en.wikipedia.org/wiki/Restricted_shell>" would be best.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkinsci-use...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-use...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/e20cbe1a-6da3-4e39-86cc-7055b5109995%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/jenkinsci-users/e20cbe1a-6da3-4e39-86cc-7055b5109995%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/d7f707c4-b56b-4a3e-a09c-9af9a9b36644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
