User access control in Docker daemon

[dimastopel]

@NathanMcCauley, @thaJeztah, @nalind,

As discussed in #13697 I'd like to start a separate discussion on the access control model in Docker daemon.

Below is the list of core principles that I think the model should be build upon:

1. The model should be pluggable, so that anyone can add / develop a plug-in that suits her needs.
2. It should be possible to add a plug-in to a deployed Docker daemon without the need to rebuild the daemon. Daemon restart may be required.
3. Each plug-in should receive the information about the user and the command she is trying to perform on each request.
4. Each plug-in should be able to influence the Docker daemon processing of the command (e.g. block the process of the current operation).

Below is the high level list of the information that each plug-in should receive and the set of possible output values for each plug-in.

Plug-in inputs:

1. The notification type: 1) The command is about to be processed 2) The response is about to be returned
2. The principal name of the user who it performing the command
3. The command that the user is doing, including all the arguments
4. The full user request, and in case of 2nd type notification the response that is about to be sent to the user

Plug-in outputs:

1. Whether the access is approved or denied
2. The message that describes why the access was approved / denied
3. Whether the next plug-in should be called or not for this specific notification (default is yes)

Improvements that I think should be done at the later stage, after the initial framework is implemented.

1. Passing the authentication method that was used to authenticate the user to the plug-ins. I think this should be done only if we find a good reason for this, and by default we should keep authentication and authorization mechanisms as de-coupled as possible.
2. Add more integration points (notifications): e.g., the authentication was just completed, the "access denied" is about to be sent, etc.
3. Add ability for the plug-in to register on specific notifications. For the sake of simplicity I wouldn't do subscription model for plug-ins right away. I think this should be treated as optimization and added only when / if needed.

Your comments are, of course, very welcome. In case the above makes sense, I'd be glad to share a more in depth design of each component and continue the discussion at a lower level.

[mheon]

I've been looking into authorization support for Docker, so I'll chime in here.

On initial inspection, I agree with the principles you've laid down, and the proposed architecture for plugins. However, I don't think the user's request alone is enough to authorize an action. As an administrator, I'd like to be able to permit or deny a request based on specific attributes of the container and/or image it targets --- for example, permit a user to attach to any container except a privileged one. To do this, commands operating on images or containers should pass the container configuration and other relevant information along to the plugin. You may have meant this when you said the arguments of a command are passed in, but I'd like to see it made explicit.

[dimastopel]

@mheon I completely agree and this is indeed what I referred to in "command arguments". Thanks for making this explicit.

[liron-l]

@NathanMcCauley, @thaJeztah, @nalind we've created a PR that contains a code skeleton for this feature. Please review #15365. You comments are very welcome.

[thaJeztah]

Thanks @liron-l ! I'll have a look and try to get some of the "core" maintainers to have a look as well 👍

[dimastopel]

@icecrime @crosbymichael @NathanMcCauley @diogomonica

We have added a detailed design document for this feature here: https://docs.google.com/document/d/1hJPEKzyL7CC8r4qRObeXixY_V3v1-QCMsdIvEGLkAsM/edit

You comments are very welcome.

Added detailed design document for the authorization feature here.

[cr7pt0gr4ph7]

I'm cross-posting #19213 (Proposal: Rename --authz-plugin to --authorization-plugin) here because it deals with the naming of the CLI flags and in the API. It therefore affects consumers of the API, as well as plugin creators, and should therefore be addressed before release.

[yajo]

This would indeed be the best solution to #13490 as I stated in #13490 (comment).

However, we must keep in mind that as long as a Docker daemon user can mount / anywhere in any container with root privileges, he can do anything. Shouldn't authorization be attached to the host's somehow? Or ability to run Docker with a non-root user?

[cpuguy83]

@yajo authorization is already supported, and you can block such a mount request.

[cyphar]

@cpuguy83 But you can only block it globally.

[cpuguy83]

@cyphar Well yes, we need authentication.

[cyphar]

I know, that was my point. ;)

[liron-l]

@cyphar @cpuguy83, if you configure Docker daemon with TLS settings, the common name is used as the username in the authorization request.

[cpuguy83]

Yeah I think this is wrong. We shouldn't be providing authn guarantees to the authz framework without actual authn...

[yajo]

Thanks for pointing that out, I had not noticed there is an authorization plugin API since Docker 1.10. However that feels like out of scope from Docker's philosophy of batteries included but swappable. There is nothing "included". Some LDAP plugin would be awesome, given it is the default auth standard nowadays, but any other kind of plugin would do the trick, given the "swappable" part of the sentence.