From 560640af831a5121cf436171855ef6deb281b91b Mon Sep 17 00:00:00 2001 From: Josh Hawn Date: Thu, 16 Feb 2017 13:47:22 -0800 Subject: [PATCH] [datacenter/ucp] Update secrets per suggestions closes #1743 Docker-DCO-1.1-Signed-off-by: Josh Hawn (github: jlhawn) --- .../user/secrets/grant-revoke-access.md | 7 +++--- .../ucp/2.1/guides/user/secrets/index.md | 23 ++++++++++++------- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/datacenter/ucp/2.1/guides/user/secrets/grant-revoke-access.md b/datacenter/ucp/2.1/guides/user/secrets/grant-revoke-access.md index 734ac9d638..1c6723793d 100644 --- a/datacenter/ucp/2.1/guides/user/secrets/grant-revoke-access.md +++ b/datacenter/ucp/2.1/guides/user/secrets/grant-revoke-access.md @@ -18,10 +18,9 @@ the secret. Users that are part of a team with access to that label will be able to see and use the secret. -In this example, if Jenny is part of -a team that has 'Restricted Control' over the `com.docker.ucp.access.label=blog` -label, she will be able to use the secret in her services, as long as the -service also has the same label. +In this example, if Jenny is part of a team that has 'Restricted Control' over +the `com.docker.ucp.access.label=blog` label, she will be able to use the +secret in her services, as long as the service also has the same label. This ensures that users can use a secret in their services without having permissions to attach to the container running the service and inspect the diff --git a/datacenter/ucp/2.1/guides/user/secrets/index.md b/datacenter/ucp/2.1/guides/user/secrets/index.md index 65df1811f7..7b660436fd 100644 --- a/datacenter/ucp/2.1/guides/user/secrets/index.md +++ b/datacenter/ucp/2.1/guides/user/secrets/index.md @@ -48,7 +48,9 @@ you won't be able to edit it or see the secret data again. ![](../../images/manage-secrets-2.png){: .with-border} Assign a unique name to the service and set its value. You can optionally define -a permission label so that other users have permission to use this secret. +a permission label so that other users have permission to use this secret. Also +note that a service and secret must have the same permission label (or both +must have no permission label at all) in order to be used together. In this example our secret is named `wordpress-password-v1`, to make it easier to track which version of the password our services are using. @@ -67,13 +69,18 @@ default configurations. Start by creating the MySQL service. Navigate to the **Services** page, click **Create Service**, and choose **Use Wizard**. Use the following configurations: -| Field | Value | -|:---------------------|:------------------------------------------------------------| -| Service name | wordpress-db | -| Image name | mysql:5.7 | -| Attached network | wordpress-network | -| Secret | wordpress-password-v1 | -| Environment variable | MYSQL_ROOT_PASSWORD_FILE=/run/secrets/wordpress-password-v1 | +| Field | Value | +|:---------------------------|:-----------------------------------| +| Service name | wordpress-db | +| Image name | mysql:5.7 | +| Attached network | wordpress-network | +| Secret | wordpress-password-v1 | +| Environment variable name | MYSQL_ROOT_PASSWORD_FILE | +| Environment variable value | /run/secrets/wordpress-password-v1 | + +Remember, if you specified a permission label on the secret, you must also set +the same permission label on this service. If the secret does not have a +permission label, then this service must also not have a permission label. This creates a MySQL service that's attached to the `wordpress-network` network, and that uses the `wordpress-password-v1`, which by default will create a file