[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Authentication/Roles Based Access Control with Docker API.
- From: Clayton Coleman <ccoleman redhat com>
- To: Jim Perrin <jperrin centos org>
- Cc: "atomic-devel projectatomic io" <atomic-devel projectatomic io>
- Subject: Re: [atomic-devel] Authentication/Roles Based Access Control with Docker API.
- Date: Fri, 21 Nov 2014 11:12:58 -0500 (EST)
It should be noted that the JWT and libtrust proposals are PKI based and rely on signed scope tokens. Assuming for the moment that those become part of docker, it's best to ask here: what actions and behaviors should be matched to which scopes? And also how standard Unix identity and groups should map to scope decisions.
> On Nov 21, 2014, at 10:59 AM, Jim Perrin <jperrin centos org> wrote:
>
>
>
>> On 11/21/2014 09:29 AM, Daniel J Walsh wrote:
>> I have begun thinking about securing the docker socket, and I wanted to
>> open a discussion on this
>> to get other peoples ideas.
>>
>> Docker currently uses group permissions to control who can connect to
>> the docker socket.
>> If you have the docker daemon listen on the network, then there is no
>> security. The ability to talk
>> to the docker socket is the equivalent of giving the user root, which I
>> blogged about here.
>>
>> http://www.projectatomic.io/blog/2014/09/granting-rights-to-users-to-use-docker-in-fedora/
>>
>> I believe we need to start working on fixing this. First I would like to
>> see authentication fixed.
>> We need some mechanism to allow administrators to specify which users
>> are able to manage docker?
>> Then once you have this, you need to manage what they are allowed to do
>> once they are connected to
>> the daemon.
>>
>> Can we have a read/only model, where a users or tool can just list the
>> running containers
>>
>> docker ps, docker images, docker inspect ...
>>
>> How do we control which users are able to start/stop docker containers?
>>
>> Who is allowed to run/create a container on a specific image?
>>
>> Who is allowed to execute a container using privileged commands?
>>
>> What is a privileged command?
>>
>> --privileged --security-opt --cap-add --cap-remove --net , --ipc ...
>>
>> Do we want fine grained control of these options?
>>
>> How can we do this without making it hopelessly complex?
>
> This probably goes against the 'hopelessly complex' part, but something
> like the mysql or postgres authentication models would be interesting,
> and would provide a method for granting users permissions to run various
> commands.
>
> e.g. docker -u jperrin -P password -H dockerhost run foo
>
>
> --
> Jim Perrin
> The CentOS Project | http://www.centos.org
> twitter: @BitIntegrity | GPG Key: FA09AD77
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]