[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: Stef Walter <stefw redhat com>
- Cc: Daniel J Walsh <dwalsh redhat com>, "atomic-devel projectatomic io" <atomic-devel projectatomic io>
- Subject: Re: [atomic-devel] Authentication/Roles Based Access Control with Docker API.
- Date: Sat, 22 Nov 2014 11:41:20 -0500 (EST)
We'll need to authorize containers to talk to docker - what limitations would polkit have in those circumstances? We can ensure we run the requesting container as a known uid, but in some cases we may need to rely on other characteristics of the container.
> On Nov 22, 2014, at 1:05 AM, Stef Walter <stefw redhat com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> On 21.11.2014 21:29, Daniel J Walsh wrote:
>>
>>> On 11/21/2014 03:19 PM, Stef Walter wrote:
>>>> On 21.11.2014 16:29, 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?
>>>
>>> I think polkit should be that mechanism. That's what all the
>>> other system services use or are migrating towards.
>>>
>>> Stef
>> Polkit is currently only used for dbus communications, I believe.
>
> It's largely used for DBus. But it is and can be used for other things
> too. See pkexec. Polkit basically for checking in a standard
> configurable way whether a subject (eg: a uid) is allowed to do
> something, much like sudo.
>
> Reusing either polkit or sudo here would be the best way to proceed
> rather than reinventing them. But there's a hybrid approach (see below).
>
>> Not sure how receptive docker would be for using polkit.
>
> That might be a problem.
>
> But integrating this well into the system is the best way to proceed,
> and not doing an NIH for every last thing. Whether Docker is open to
> the best approach or not is another matter.
>
>> Also this function needs to be managed. IE How do I add a user to
>> be able to launch certain containers. Seems like it would need
>> some kind of database internal to docker.
>
> There are two ways to do this:
>
> * In polkit this can be done by adding rules files which check
> whether a user can do X with Y and grant permission, taking all
> these things into account.
>
> * Or you can have the database of who can do what internal to docker
> and just use polkit or sudo to authorize the subject, and then make
> access control decisions based on the database.
>
> Stef
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlRwNboACgkQe/sRCNknZa9lfgCeOWLyITMSYQARq/pgfuGTIFvJ
> LGkAn3Fq2Uw1rK2BJ0nZHHrLJ0e8Tuwl
> =rmH9
> -----END PGP SIGNATURE-----
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]