Configuring Secrets and Configs in Docker Compose Quiz

Explore essential concepts of managing secrets and configs with Docker Compose. This quiz covers secure handling techniques, file definitions, usage scopes, command requirements, and error prevention strategies related to secrets and configs.

1. Defining a Secret in Docker Compose

   Which of the following is the correct way to define a secret from a file in a Docker Compose YAML file, using the 'secrets' section?

   1. my_secret:n file: ./secret.txt
   2. mysecret:n filepath: ./secret.txt
   3. mySecret:n data: ./secret.txt
   4. mysecret:n files: ./secret.txt

   Explanation: The correct syntax for defining a secret from a file in Docker Compose is by using the secret's name followed by 'file:' and the path to the file. Options with keys like 'filepath', 'data', or 'files' are invalid because only 'file' is recognized for this purpose. Also, the secret's name should match the reference used in the service. Using any typos or alternative attributes will result in configuration errors or ignored secrets.

2. Distinction Between 'configs' and 'secrets'

   When should you use the 'configs' feature over 'secrets' in Docker Compose for a web server's public configuration file?

   1. When storing non-sensitive, environment-specific configuration data
   2. When storing sensitive database passwords
   3. When securing TLS private keys
   4. When providing user credentials

   Explanation: The 'configs' feature is intended for non-sensitive configuration data that is environment-specific, like public web server settings. 'Secrets' should be used for confidential information such as database passwords or private keys, as they are handled more securely. User credentials are also sensitive and belong in 'secrets'. Using 'configs' for sensitive data risks exposing information unintentionally.

3. Secret Usage Scope in Services

   If you define multiple secrets in the 'secrets' section of a Docker Compose file, which statement correctly describes how they are available to services?

   1. Secrets are only available to services that explicitly reference them in their configuration
   2. All services automatically inherit all defined secrets
   3. Secrets are available system-wide without any restrictions
   4. Secrets must be passed as runtime command arguments to services

   Explanation: A secret is only mounted and visible to a service if that service lists the secret in its own 'secrets' section. Secrets are not inherited globally, nor are they available to unrelated services. They are not system-wide nor injected as command-line arguments by default. Explicit referencing minimizes exposure and enhances security.

4. Command Requirement for Using Secrets

   Which Docker Compose command is required to use secrets and configs with services, considering their dependency on orchestrator features?

   1. docker compose up --detach
   2. docker stack deploy -c docker-compose.yml mystack
   3. docker compose build
   4. docker run --secret

   Explanation: Using secrets and configs requires the orchestrator deployment command, such as 'docker stack deploy', rather than the standard 'docker compose up'. Regular compose commands do not integrate the secrets/configs features. 'docker compose build' only builds images without deployment, and 'docker run --secret' is not a Docker Compose command. Choosing the wrong command prevents secrets from being made available.

5. Preventing Secrets Leaks in Environment Variables

   Why is it recommended not to inject secrets as environment variables inside containers when using Docker Compose?

   1. Environment variables are easily visible via process inspection inside the container
   2. Environment variables automatically encrypt data
   3. Secrets cannot be accessed by applications via environment variables
   4. Config files are always preferred by all applications

   Explanation: Injecting secrets as environment variables exposes them through process lists and inspection tools, creating a security risk. Environment variables do not provide encryption or heightened protection. While secrets can be accessed as environment variables, this makes them vulnerable to leaks. Not all applications prefer config files; the method depends on the application's design.