Environment variables for sensitive values

Use environment variables instead of hardcoded values for passwords, secrets, tokens, keys, and other sensitive data in your Authorization Hub configuration. This is the recommended security best practice.

When you reference an environment variable, Authorization Hub stores only the reference, such as ${LDAP_PASSWORD}, and not the secret itself. As a result:

• The secret does not appear in your project's configuration.
• The secret is not included in exported attribute connector files, which otherwise contain credentials in plain text.
• You can use the same configuration across environments, such as development, test, and production, and supply a different value in each one.
• You can rotate a secret in the environment without editing the attribute connector in Authorization Hub.

Syntax

Reference an environment variable with the following syntax:

${<environment_variable_name>:<default_value>}

where:

• <environment_variable_name> is the name of the environment variable to read, for example LDAP_PASSWORD.
• :<default_value> (optional) is the value to use when the environment variable is not defined. Omit it to have no default value.

For example:

Reference	Result
${LDAP_PASSWORD}	The value of LDAP_PASSWORD. No default value is used.
${LDAP_PRINCIPAL:svc-dev}	The value of LDAP_PRINCIPAL, or svc-dev if the variable is not set.

warning

Never use a real secret as a default value. A default value is stored in the configuration in plain text, exactly like a literal value. Use defaults only for non-sensitive values, such as a development-only account name.

The variable is resolved by ADS when it loads the domain, not by Authorization Hub. Authorization Hub does not check that the variable exists. If a variable is not defined and has no default value, the configuration that references it will fail when ADS uses it, so verify the value in each environment.

Best practices

• Name variables after the system and the credential they hold, for example HR_DB_PASSWORD, so that it is clear what each one is for.
• Store the actual values in a secrets manager, such as a Kubernetes secret, and expose them to ADS as environment variables, instead of writing them in deployment files.
• Do not store real secrets into Authorization Hub fields, even temporarily. Anything saved in a field is part of the configuration and appears in exports.
• Review existing configurations that contain literal credentials and replace them with environment variable references.