deleted file mode 100644

@@ -1,253 +0,0 @@

-<!--[metadata]>

-+++

-title = "Access authorization plugin"

-description = "How to create authorization plugins to manage access control to your Docker daemon."

-keywords = ["security, authorization, authentication, docker, documentation, plugin, extend"]

-[menu.main]

-parent = "engine_extend"

-weight = -1

-+++

-<![end-metadata]-->

-

-

-# Create an authorization plugin

-

-Docker's out-of-the-box authorization model is all or nothing. Any user with

-permission to access the Docker daemon can run any Docker client command. The

-same is true for callers using Docker's remote API to contact the daemon. If you

-require greater access control, you can create authorization plugins and add

-them to your Docker daemon configuration. Using an authorization plugin, a

-Docker administrator can configure granular access policies for managing access

-to Docker daemon.

-

-Anyone with the appropriate skills can develop an authorization plugin. These

-skills, at their most basic, are knowledge of Docker, understanding of REST, and

-sound programming knowledge. This document describes the architecture, state,

-and methods information available to an authorization plugin developer.

-

-## Basic principles

-

-Docker's [plugin infrastructure](plugin_api.md) enables

-extending Docker by loading, removing and communicating with

-third-party components using a generic API. The access authorization subsystem

-was built using this mechanism.

-

-Using this subsystem, you don't need to rebuild the Docker daemon to add an

-authorization plugin.  You can add a plugin to an installed Docker daemon. You do

-need to restart the Docker daemon to add a new plugin.

-

-An authorization plugin approves or denies requests to the Docker daemon based

-on both the current authentication context and the command context. The

-authentication context contains all user details and the authentication method.

-The command context contains all the relevant request data.

-

-Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md).

-Each plugin must reside within directories described under the

-[Plugin discovery](plugin_api.md#plugin-discovery) section.

-

-**Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication

-respectively.

-

-## Basic architecture

-

-You are responsible for registering your plugin as part of the Docker daemon

-startup. You can install multiple plugins and chain them together. This chain

-can be ordered. Each request to the daemon passes in order through the chain.

-Only when all the plugins grant access to the resource, is the access granted.

-

-When an HTTP request is made to the Docker daemon through the CLI or via the

-remote API, the authentication subsystem passes the request to the installed

-authentication plugin(s). The request contains the user (caller) and command

-context. The plugin is responsible for deciding whether to allow or deny the

-request.

-

-The sequence diagrams below depict an allow and deny authorization flow:

-

-![Authorization Allow flow](images/authz_allow.png)

-

-![Authorization Deny flow](images/authz_deny.png)

-

-Each request sent to the plugin includes the authenticated user, the HTTP

-headers, and the request/response body. Only the user name and the

-authentication method used are passed to the plugin. Most importantly, no user

-credentials or tokens are passed. Finally, not all request/response bodies

-are sent to the authorization plugin. Only those request/response bodies where

-the `Content-Type` is either `text/*` or `application/json` are sent.

-

-For commands that can potentially hijack the HTTP connection (`HTTP

-Upgrade`), such as `exec`, the authorization plugin is only called for the

-initial HTTP requests. Once the plugin approves the command, authorization is

-not applied to the rest of the flow. Specifically, the streaming data is not

-passed to the authorization plugins. For commands that return chunked HTTP

-response, such as `logs` and `events`, only the HTTP request is sent to the

-authorization plugins.

-

-During request/response processing, some authorization flows might

-need to do additional queries to the Docker daemon. To complete such flows,

-plugins can call the daemon API similar to a regular user. To enable these

-additional queries, the plugin must provide the means for an administrator to

-configure proper authentication and security policies.

-

-## Docker client flows

-

-To enable and configure the authorization plugin, the plugin developer must

-support the Docker client interactions detailed in this section.

-

-### Setting up Docker daemon

-

-Enable the authorization plugin with a dedicated command line flag in the

-`--authorization-plugin=PLUGIN_ID` format. The flag supplies a `PLUGIN_ID`

-value. This value can be the plugin’s socket or a path to a specification file.

-

-```bash

-$ docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...

-```

-

-Docker's authorization subsystem supports multiple `--authorization-plugin` parameters.

-

-### Calling authorized command (allow)

-

-```bash

-$ docker pull centos

-...

-f1b10cd84249: Pull complete

-...

-```

-

-### Calling unauthorized command (deny)

-

-```bash

-$ docker pull centos

-...

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

-```

-

-### Error from plugins

-

-```bash

-$ 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 schema and implementation

-

-In addition to Docker's standard plugin registration method, each plugin

-should implement the following two methods:

-

-* `/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**:

-

-```json

-{

-    "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 ",

-    "RequestStatusCode": "Request status code"

-}

-```

-

-**Response**:

-

-```json

-{

-    "Allow": "Determined whether the user is allowed or not",

-    "Msg":   "The authorization message",

-    "Err":   "The error message if things go wrong"

-}

-```

-#### /AuthzPlugin.AuthZRes

-

-**Request**:

-

-```json

-{

-    "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",

-    "RequestStatusCode": "Request status code",

-    "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**:

-

-```json

-{

-   "Allow":              "Determined whether the user is allowed or not",

-   "Msg":                "The authorization message",

-   "Err":                "The error message if things go wrong",

-   "ModifiedBody":       "Byte array containing a modified body of the raw HTTP body (or nil if no changes required)",

-   "ModifiedHeader":     "Byte array containing a modified header of the HTTP response (or nil if no changes required)",

-   "ModifiedStatusCode": "int containing the modified version of the status code (or 0 if not change is required)"

-}

-```

-

-The modified response enables the authorization plugin to manipulate the content

-of the HTTP response. In case of more than one plugin, each subsequent plugin

-receives a response (optionally) modified by a previous plugin.

-

-### 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

-

-Name                   | Type              | Description

-User                   | string            | The user identification

-Authentication method  | string            | The authentication method used

-Request method         | enum              | The HTTP method (GET/DELETE/POST)

-Request URI            | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)

-Request headers        | map[string]string | Request headers as key value pairs (without the authorization header)

-Request body           | []byte            | Raw request body

-

-

-#### Plugin -> Daemon

-

-Name    | Type   | Description

-Allow   | bool   | Boolean value indicating whether the request is allowed or denied

-Msg     | string | Authorization message (will be returned to the client in case the access is denied)

-Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

-

-### 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

-

-

-Name                    | Type              | Description

-User                    | string            | The user identification

-Authentication method   | string            | The authentication method used

-Request method          | string            | The HTTP method (GET/DELETE/POST)

-Request URI             | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)

-Request headers         | map[string]string | Request headers as key value pairs (without the authorization header)

-Request body            | []byte            | Raw request body

-Response status code    | int               | Status code from the docker daemon

-Response headers        | map[string]string | Response headers as key value pairs

-Response body           | []byte            | Raw docker daemon response body

-

-

-#### Plugin -> Daemon

-

-Name    | Type   | Description

-Allow   | bool   | Boolean value indicating whether the response is allowed or denied

-Msg     | string | Authorization message (will be returned to the client in case the access is denied)

-Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

@@ -18,5 +18,5 @@ Currently, you can extend Docker Engine by adding a plugin. This section contain

 * [Understand Docker plugins](plugins.md)

 * [Write a volume plugin](plugins_volume.md)

 * [Write a network plugin](plugins_network.md)

-* [Write an authorization plugin](authorization.md)

+* [Write an authorization plugin](plugins_authorization.md)

 * [Docker plugin API](plugin_api.md)

@@ -96,6 +96,43 @@ directory and activates it with a handshake. See Handshake API below.

 Plugins are *not* activated automatically at Docker daemon startup. Rather,

 they are activated only lazily, or on-demand, when they are needed.

+## Systemd socket activation

+

+Plugins may also be socket activated by `systemd`. The official [Plugins helpers](https://github.com/docker/go-plugins-helpers)

+natively supports socket activation. In order for a plugin to be socket activated it needs

+a `service` file and a `socket` file.

+

+The `service` file (for example `/lib/systemd/system/your-plugin.service`):

+

+```

+[Unit]

+Description=Your plugin

+Before=docker.service

+After=network.target your-plugin.socket

+Requires=your-plugin.socket docker.service

+

+[Service]

+ExecStart=/usr/lib/docker/your-plugin

+

+[Install]

+WantedBy=multi-user.target

+```

+The `socket` file (for example `/lib/systemd/system/your-plugin.socket`):

+```

+[Unit]

+Description=Your plugin

+

+[Socket]

+ListenStream=/run/docker/plugins/your-plugin.sock

+

+[Install]

+WantedBy=sockets.target

+```

+

+This will allow plugins to be actually started when the Docker daemon connects to

+the sockets they're listening on (for instance the first time the daemon uses them

+or if one of the plugin goes down accidentally).

+

 ## API design

 The Plugin API is RPC-style JSON over HTTP, much like webhooks.

@@ -128,7 +165,7 @@ Responds with a list of Docker subsystems which this plugin implements.

 After activation, the plugin will then be sent events from this subsystem.

 Possible values are:

- - [`authz`](authorization.md)

+ - [`authz`](plugins_authorization.md)

  - [`NetworkDriver`](plugins_network.md)

  - [`VolumeDriver`](plugins_volume.md)

@@ -139,3 +176,8 @@ Attempts to call a method on a plugin are retried with an exponential backoff

 for up to 30 seconds. This may help when packaging plugins as containers, since

 it gives plugin containers a chance to start up before failing any user

 containers which depend on them.

+

+## Plugins helpers

+

+To ease plugins development, we're providing an `sdk` for each kind of plugins

+currently supported by Docker at [docker/go-plugins-helpers](https://github.com/docker/go-plugins-helpers).

new file mode 100644

@@ -0,0 +1,254 @@

+<!--[metadata]>

+title = "Access authorization plugin"

+description = "How to create authorization plugins to manage access control to your Docker daemon."

+keywords = ["security, authorization, authentication, docker, documentation, plugin, extend"]

+aliases = ["/engine/extend/authorization/"]

+[menu.main]

+parent = "engine_extend"

+weight = -1

+<![end-metadata]-->

+

+

+# Create an authorization plugin

+

+Docker's out-of-the-box authorization model is all or nothing. Any user with

+permission to access the Docker daemon can run any Docker client command. The

+same is true for callers using Docker's remote API to contact the daemon. If you

+require greater access control, you can create authorization plugins and add

+them to your Docker daemon configuration. Using an authorization plugin, a

+Docker administrator can configure granular access policies for managing access

+to Docker daemon.

+

+Anyone with the appropriate skills can develop an authorization plugin. These

+skills, at their most basic, are knowledge of Docker, understanding of REST, and

+sound programming knowledge. This document describes the architecture, state,

+and methods information available to an authorization plugin developer.

+

+## Basic principles

+

+Docker's [plugin infrastructure](plugin_api.md) enables

+extending Docker by loading, removing and communicating with

+third-party components using a generic API. The access authorization subsystem

+was built using this mechanism.

+

+Using this subsystem, you don't need to rebuild the Docker daemon to add an

+authorization plugin.  You can add a plugin to an installed Docker daemon. You do

+need to restart the Docker daemon to add a new plugin.

+

+An authorization plugin approves or denies requests to the Docker daemon based

+on both the current authentication context and the command context. The

+authentication context contains all user details and the authentication method.

+The command context contains all the relevant request data.

+

+Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md).

+Each plugin must reside within directories described under the

+[Plugin discovery](plugin_api.md#plugin-discovery) section.

+

+**Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication

+respectively.

+

+## Basic architecture

+

+You are responsible for registering your plugin as part of the Docker daemon

+startup. You can install multiple plugins and chain them together. This chain

+can be ordered. Each request to the daemon passes in order through the chain.

+Only when all the plugins grant access to the resource, is the access granted.

+

+When an HTTP request is made to the Docker daemon through the CLI or via the

+remote API, the authentication subsystem passes the request to the installed

+authentication plugin(s). The request contains the user (caller) and command

+context. The plugin is responsible for deciding whether to allow or deny the

+request.

+

+The sequence diagrams below depict an allow and deny authorization flow:

+

+![Authorization Allow flow](images/authz_allow.png)

+

+![Authorization Deny flow](images/authz_deny.png)

+

+Each request sent to the plugin includes the authenticated user, the HTTP

+headers, and the request/response body. Only the user name and the

+authentication method used are passed to the plugin. Most importantly, no user

+credentials or tokens are passed. Finally, not all request/response bodies

+are sent to the authorization plugin. Only those request/response bodies where

+the `Content-Type` is either `text/*` or `application/json` are sent.

+

+For commands that can potentially hijack the HTTP connection (`HTTP

+Upgrade`), such as `exec`, the authorization plugin is only called for the

+initial HTTP requests. Once the plugin approves the command, authorization is

+not applied to the rest of the flow. Specifically, the streaming data is not

+passed to the authorization plugins. For commands that return chunked HTTP

+response, such as `logs` and `events`, only the HTTP request is sent to the

+authorization plugins.

+

+During request/response processing, some authorization flows might

+need to do additional queries to the Docker daemon. To complete such flows,

+plugins can call the daemon API similar to a regular user. To enable these

+additional queries, the plugin must provide the means for an administrator to

+configure proper authentication and security policies.

+

+## Docker client flows

+

+To enable and configure the authorization plugin, the plugin developer must

+support the Docker client interactions detailed in this section.

+

+### Setting up Docker daemon

+

+Enable the authorization plugin with a dedicated command line flag in the

+`--authorization-plugin=PLUGIN_ID` format. The flag supplies a `PLUGIN_ID`

+value. This value can be the plugin’s socket or a path to a specification file.

+

+```bash

+$ docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...

+```

+

+Docker's authorization subsystem supports multiple `--authorization-plugin` parameters.

+

+### Calling authorized command (allow)

+

+```bash

+$ docker pull centos

+...

+f1b10cd84249: Pull complete

+...

+```

+

+### Calling unauthorized command (deny)

+

+```bash

+$ docker pull centos

+...

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

+```

+

+### Error from plugins

+

+```bash

+$ 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 schema and implementation

+

+In addition to Docker's standard plugin registration method, each plugin

+should implement the following two methods:

+

+* `/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**:

+

+```json

+{

+    "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 ",

+    "RequestStatusCode": "Request status code"

+}

+```

+

+**Response**:

+

+```json

+{

+    "Allow": "Determined whether the user is allowed or not",

+    "Msg":   "The authorization message",

+    "Err":   "The error message if things go wrong"

+}

+```

+#### /AuthzPlugin.AuthZRes

+

+**Request**:

+

+```json

+{

+    "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",

+    "RequestStatusCode": "Request status code",

+    "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**:

+

+```json

+{

+   "Allow":              "Determined whether the user is allowed or not",

+   "Msg":                "The authorization message",

+   "Err":                "The error message if things go wrong",

+   "ModifiedBody":       "Byte array containing a modified body of the raw HTTP body (or nil if no changes required)",

+   "ModifiedHeader":     "Byte array containing a modified header of the HTTP response (or nil if no changes required)",

+   "ModifiedStatusCode": "int containing the modified version of the status code (or 0 if not change is required)"

+}

+```

+

+The modified response enables the authorization plugin to manipulate the content

+of the HTTP response. In case of more than one plugin, each subsequent plugin

+receives a response (optionally) modified by a previous plugin.

+

+### 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

+

+Name                   | Type              | Description

+-----------------------|-------------------|-------------------------------------------------------

+User                   | string            | The user identification

+Authentication method  | string            | The authentication method used

+Request method         | enum              | The HTTP method (GET/DELETE/POST)

+Request URI            | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)

+Request headers        | map[string]string | Request headers as key value pairs (without the authorization header)

+Request body           | []byte            | Raw request body

+

+

+#### Plugin -> Daemon

+

+Name    | Type   | Description

+--------|--------|----------------------------------------------------------------------------------

+Allow   | bool   | Boolean value indicating whether the request is allowed or denied

+Msg     | string | Authorization message (will be returned to the client in case the access is denied)

+Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

+

+### 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

+

+

+Name                    | Type              | Description

+----------------------- |------------------ |----------------------------------------------------

+User                    | string            | The user identification

+Authentication method   | string            | The authentication method used

+Request method          | string            | The HTTP method (GET/DELETE/POST)

+Request URI             | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)

+Request headers         | map[string]string | Request headers as key value pairs (without the authorization header)

+Request body            | []byte            | Raw request body

+Response status code    | int               | Status code from the docker daemon

+Response headers        | map[string]string | Response headers as key value pairs

+Response body           | []byte            | Raw docker daemon response body

+

+

+#### Plugin -> Daemon

+

+Name    | Type   | Description

+--------|--------|----------------------------------------------------------------------------------

+Allow   | bool   | Boolean value indicating whether the response is allowed or denied

+Msg     | string | Authorization message (will be returned to the client in case the access is denied)

+Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

@@ -644,7 +644,7 @@ multiple plugins installed, at least one must allow the request for it to

 complete.

 For information about how to create an authorization plugin, see [authorization

-plugin](../../extend/authorization.md) section in the Docker extend section of this documentation.

+plugin](../../extend/plugins_authorization.md) section in the Docker extend section of this documentation.

 ## Daemon user namespace options

@@ -521,7 +521,7 @@ multiple plugins installed, at least one must allow the request for it to

 complete.

 For information about how to create an authorization plugin, see [authorization

-plugin](https://docs.docker.com/engine/extend/authorization.md) section in the

+plugin](https://docs.docker.com/engine/extend/plugins_authorization.md) section in the

 Docker extend section of this documentation.