Manage secret aliases
A secret alias maps a logical name to a specific secret path within a secret provider. Automation references the alias name rather than the provider or path. If you change providers or rotate to a different secret path, update the alias—nothing else in your automation needs to change.
Prerequisites
- At least one secret provider configured
Create a secret alias
When the secret value is a JSON object and you want to extract a specific field, add --key:
The format of --secret depends on the provider type:
- Vault: the path within the secrets mount, for example
myapp/creds. The mount prefix from the provider’s--secrets-endpointis prepended automatically. - CyberArk:
SafeName/ObjectName, for exampleProdSafe/DB_Production_Password. - Plugin: passed as-is to the plugin subprocess.
Example: Create an alias called db-password that retrieves the password field from the Vault path secret/data/my-app:
Example: Create an alias called db-password that retrieves a CyberArk-managed credential:
View secret aliases
List all aliases:
View details for a specific alias:
Delete a secret alias
Deleting an alias does not affect the underlying secret in the external provider.
Reference a secret alias
Use the following syntax anywhere Gateway accepts a secret:
The parentheses delimit the alias name for unambiguous parsing when embedded in strings.
Code on Canvas
Reference a secret alias inline. The executing gateway resolves the alias at execution time:
Inventory Manager
Set a device credential value to $GATEWAYSECRET_(alias-name). The alias resolves each time a workflow runs against the device.
Services and repositories
Alias names work anywhere Gateway accepts a secret name. See Inject secrets into services for service injection syntax, and Configure private repository access and Use SSH keys to clone git repositories for repository credential setup.