[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.



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]