访问授权插件

本文档介绍了Docker Engine中通常可用的Docker Engine插件。要查看有关由Docker Engine管理的插件的信息，请参阅Docker Engine插件系统。

Docker开箱即用的授权模型是全有还是全无。任何有权访问Docker守护程序的用户都可以运行任何Docker客户端命令。使用Docker的Engine API与守护程序联系的调用者也是如此。如果需要更好的访问控制，则可以创建授权插件并将其添加到Docker守护程序配置中。Docker管理员可以使用授权插件配置精细的访问策略，以管理对Docker守护程序的访问。

具有适当技能的任何人都可以开发授权插件。这些技能最基本的是Docker知识，REST知识和良好的编程知识。本文档描述了授权插件开发人员可以使用的体系结构，状态和方法信息。

基本原则

Docker的插件基础结构可通过使用通用API加载，删除第三方组件并与之通信来扩展Docker。访问授权子系统是使用此机制构建的。

使用此子系统，您无需重建Docker守护进程即可添加授权插件。您可以将插件添加到已安装的Docker守护程序中。您确实需要重新启动Docker守护程序以添加新插件。

授权插件基于当前身份验证上下文和命令上下文批准或拒绝对Docker守护程序的请求。身份验证上下文包含所有用户详细信息和身份验证方法。命令上下文包含所有相关的请求数据。

授权插件必须遵循Docker Plugin API中描述的规则。每个插件必须位于“插件发现”部分下描述的目录内 。

笔记

缩写AuthZ和AuthN均指授权和认证。

默认的用户授权机制

如果在Docker守护程序中启用了TLS ，则默认用户授权流程将从证书使用者名称中提取用户详细信息。即，该User字段设置为客户端证书主题的通用名称，而该AuthenticationMethod字段设置为TLS。

基本架构

您有责任在Docker守护程序启动过程中注册插件。您可以安装多个插件并将它们链接在一起。可以订购此链条。对守护程序的每个请求均按顺序通过链。仅当所有插件都授予对资源的访问权限时，才授予访问权限。

通过CLI或通过Engine API向Docker守护程序发出HTTP请求时，身份验证子系统会将请求传递给已安装的身份验证插件。该请求包含用户（调用者）和命令上下文。该插件负责决定是允许还是拒绝该请求。

下面的序列图描述了允许和拒绝授权流程：

发送到插件的每个请求都包括经过身份验证的用户，HTTP标头和请求/响应主体。仅将使用的用户名和身份验证方法传递给插件。最重要的是，没有传递用户凭证或令牌。最后，并非所有请求/响应主体都发送到授权插件。只有那些请求/响应机构，其中Content-Type或者是text/*或application/json被发送。

对于可能会劫持HTTP连接（HTTP Upgrade）的命令，例如exec，仅针对初始HTTP请求调用授权插件。插件批准命令后，授权将不会应用于其余流程。具体来说，流数据不会传递到授权插件。对于返回分块HTTP响应的命令（例如logs和）events，仅将HTTP请求发送到授权插件。

在请求/响应处理期间，某些授权流程可能需要对Docker守护程序进行其他查询。为了完成这样的流程，插件可以像普通用户一样调用守护程序API。要启用这些其他查询，插件必须为管理员提供配置适当的身份验证和安全策略的方法。

Docker客户端流程

要启用和配置授权插件，插件开发人员必须支持本节中详细介绍的Docker客户端交互。

设置Docker守护程序

使用--authorization-plugin=PLUGIN_ID格式的专用命令行标记启用授权插件 。该标志提供一个PLUGIN_ID 值。该值可以是插件的套接字，也可以是规范文件的路径。可以在不重新启动守护程序的情况下加载授权插件。有关更多信息，请参考dockerd文档。

$ dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...

Docker的授权子系统支持多个--authorization-plugin参数。

调用授权命令（允许）

$ docker pull centos
...
f1b10cd84249: Pull complete
...

调用未经授权的命令（拒绝）

$ docker pull centos
...
docker: Error response from daemon: authorization denied by plugin PLUGIN_NAME: volumes are not allowed.

插件错误

$ docker pull centos
...
docker: Error response from daemon: plugin PLUGIN_NAME failed with error: AuthZPlugin.AuthZReq: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.

API模式和实现

除了Docker的标准插件注册方法外，每个插件还应实现以下两种方法：

• /AuthZPlugin.AuthZReq This authorize request method is called before the Docker daemon processes the client request.

• /AuthZPlugin.AuthZRes This authorize response method is called before the response is returned from Docker daemon to the client.

/AuthZPlugin.AuthZReq

Request:

{
    "User":              "The user identification",
    "UserAuthNMethod":   "The authentication method used",
    "RequestMethod":     "The HTTP method",
    "RequestURI":        "The HTTP request URI",
    "RequestBody":       "Byte array containing the raw HTTP request body",
    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string "
}

Response:

{
    "Allow": "Determined whether the user is allowed or not",
    "Msg":   "The authorization message",
    "Err":   "The error message if things go wrong"
}

/AuthZPlugin.AuthZRes

Request:

{
    "User":              "The user identification",
    "UserAuthNMethod":   "The authentication method used",
    "RequestMethod":     "The HTTP method",
    "RequestURI":        "The HTTP request URI",
    "RequestBody":       "Byte array containing the raw HTTP request body",
    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string",
    "ResponseBody":      "Byte array containing the raw HTTP response body",
    "ResponseHeader":    "Byte array containing the raw HTTP response header as a map[string][]string",
    "ResponseStatusCode":"Response status code"
}

Response:

{
   "Allow":              "Determined whether the user is allowed or not",
   "Msg":                "The authorization message",
   "Err":                "The error message if things go wrong"
}

Request authorization

Each plugin must support two request authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.

Daemon -> Plugin

Plugin -> Daemon

Response authorization

The plugin must support two authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.

Daemon -> Plugin

Plugin -> Daemon