# As an alternative to using secrets.yml, you can also store your secrets
# in Vault.
#
# In this file, the following variables will be replaced:
#
#     $PROJECT    The name of the project (-p)
#     $OVERRIDE   The name of the current override
#     $POD        The name of the pod
#     $SERVICE    The name of the service

# By default, we only want to enable this plugin in production mode (and
# staging if we have it).  For local development, either specify fake
# secrets somewhere in `pods/overrides/development`, or use the `secrets`
# plugin for real secrets.
enable_in_overrides:
- "production"

# How should individual services authenticate themselves to vault?  The only
# supported value for now is "token".
#
# token:
#
#   To use this, set the environment variables `VAULT_ADDR` and
#   `VAULT_MASTER_TOKEN` before running conductor.  These values will be
#   used to construct per-service `VAULT_TOKEN` values, which be added
#   to the appropriate services along with `VAULT_ADDR`.
auth_type: "token"

# Extra environment variables to add to each service.
extra_environment:
  VAULT_ENV: "$OVERRIDE"

# How long should the generated tokens be valid for, in seconds?
default_ttl: 2592000

# We use these templates to construct the names of policies to apply to our
# project.
default_policies:
  - "$PROJECT-$OVERRIDE"
  - "$PROJECT-$OVERRIDE-$POD-$SERVICE"

# If you want to apply addition policies to particular pods, you may also
# override them as follows.
pods:
  frontend:
    web:
      policies:
        - "$PROJECT-$OVERRIDE-ssl"