edit-icon download-icon

Use secrets in a service

Last Updated: Feb 06, 2018

You can specify the secrets used in a service by creating an application. You can also grant the service the permission to use one or more secrets.

Prerequisites

You have created a secret. For how to create a secret, see Create a secret.

Limits

The secret and the application using this secret must be in the same cluster.

Create an application by using an image

For how to create an application, see Create an application.

In this example, create a MySQL application named mysql. Configure the secret information in the Secrets section of the application configuration. In this example, grant the application to use these two secrets: my_mysql_password_v1 and my_secret_v1.

1

Wherein:

  • Name: The name of the secret you created in Container Service.
  • Target: The name of the file that will be mounted to the container /run/secrets/ directory. By default, the value is the same as source, namely, the container accesses the secret in the /run/secrets/<secret_name> directory.
  • User Id: The ID of the user who owns the secret file in the container /run/secrets/ directory. The default value is 0.
  • Group Id: The ID of the group who owns the secret file in the container /run/secrets/ directory. The default value is 0.
  • Mode: The permission of the secret file that will be mounted to the container /run/secrets/ directory. The format is octal. For example, 0444 indicates to be globally readable. Secrets are not writable because they are mounted to the temporary file system. Therefore, if you configure the writable bit, the system will ignore your configurations. Use Permission Calculator if you are not familiar with UNIX permission mode.

In addition, in this example, you must set the environment variable MYSQL_ROOT_PASSWORD_FILE to configure the MySQL application to use the /run/secrets/my_mysql file as the root password.

1

Create an application by using an orchestration template

For how to create an application, see Create an application.

You can use short syntax or long syntax to set secrets in the orchestration template.

Short syntax

To use the short syntax, specify the secret name. Then, Container Service grants the container the permission to access the secret and mount the secret to the container /run/secrets/<secret_name> directory.

In this example, create an application named mysqlshort. Add the secret information in the orchestration template. In this example, grant the application to use these two secrets: my_mysql_password_v1 and my_secret_v1.

1

Orchestration sample:

  1. version: '3.2'
  2. services:
  3. mysqlshort:
  4. image: 'mysql:5.7'
  5. deploy:
  6. mode: replicated
  7. replicas: 1
  8. update_config:
  9. failure_action: continue
  10. restart_policy:
  11. condition: none
  12. environment:
  13. - MYSQL_ROOT_PASSWORD=/run/secrets/my_mysql_password_v1 #Configure the MySQL application to use the '/run/secrets/my_mysql_password_v1' file as the root password.
  14. secrets:
  15. - my_mysql_password_v1 #The name of the secret you created.
  16. - my_secret_v1 #The name of the secret you created.
  17. secrets: #Declare the secrets.
  18. my_mysql_password_v1:
  19. external: true
  20. my_secret_v1:
  21. external: true

You must declare the secrets in the orchestration template. Otherwise, the secrets will not take effect. external:true indicates that the secrets have been created. Therefore, Container Service will not try to create the secrets, but will search for the secrets and apply them to the service.

Long syntax

You can specify related secret parameters by using long syntax.

In this example, create an application named mysqllong. Add the secret information in the orchestration template. In this example, grant the application to use these two secrets: my_mysql_password_v1 and my_secret_v1.

2

Orchestration sample:

  1. version: '3.2'
  2. services:
  3. mysqllong:
  4. image: 'mysql:5.7'
  5. deploy:
  6. mode: replicated
  7. replicas: 1
  8. update_config:
  9. failure_action: continue
  10. restart_policy:
  11. condition: none
  12. environment:
  13. - MYSQL_ROOT_PASSWORD=/run/secrets/my_mysql#Configure the MySQL application to use the '/run/secrets/my_mysql_password_v1' file as the root password.
  14. secrets:
  15. - source: my_mysql_password_v1 #The name of the secret you created.
  16. target: my_mysql
  17. uid: '0'
  18. gid: '0'
  19. mode: 444
  20. - source: my_secret_v1 #The name of the secret you created.
  21. target: my_secret
  22. uid: '0'
  23. gid: '0'
  24. mode: 444
  25. secrets: #Declare the secrets.
  26. my_mysql_password_v1:
  27. external: true
  28. my_secret_v1:
  29. external: true

Wherein:

  • source: The name of the secret you created in Container Service.
  • target: The name of the file that will be mounted to the container /run/secrets/ directory. By default, the value is the same as source, namely, the container accesses the secret in the /run/secrets/<secret_name> directory.
  • uid: The ID of the user who owns the secret file in the container /run/secrets/ directory. The default value is 0.
  • gid: The ID of the group who owns the secret file in the container /run/secrets/ directory. The default value is 0.
  • mode: The permission of the secret file that will be mounted to the container /run/secrets/ directory. The format is octal. For example, 0444 indicates to be globally readable. Secrets are not writable because they are mounted to the temporary file system. Therefore, if you configure the writable bit, the system will ignore your configurations. Use Permission Calculator if you are not familiar with UNIX permission mode.

You must declare the secrets in the orchestration template. Otherwise, the secrets will not take effect. external:true indicates that the secrets have been created. Therefore, Container Service will not try to create the secrets, but will search for the secrets and apply them to the service.

Thank you! We've received your feedback.