docs/current_docs/introduction/features/secrets.mdx
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; import VideoPlayer from '@components/VideoPlayer';
Dagger natively supports reading confidential information ("secrets"), such as passwords, API keys, SSH keys, and access tokens, from multiple secret providers and has built-in safeguards to ensure that secrets do not leak into the open.
These secrets can be sourced from different secret providers, including the host environment, the host filesystem, the result of host command execution, and external secret managers 1Password, Vault, and AWS Secrets Manager/Parameter Store.
:::important Dagger has built-in safeguards to ensure that secrets are used without exposing them in plaintext logs, writing them into the filesystem of containers you're building, or inserting them into the cache. This ensures that sensitive data does not leak - for example, in the event of a crash. :::
Here's an example of a workflow that receives and uses a GitHub personal access token as a secret:
<Tabs groupId="language" queryString="sdk"> <TabItem value="go" label="Go"> ```go file=./snippets/secrets/go/main.go ``` </TabItem> <TabItem value="python" label="Python"> ```python file=./snippets/secrets/python/main.py ``` </TabItem> <TabItem value="typescript" label="TypeScript"> ```typescript file=./snippets/secrets/typescript/index.ts ``` </TabItem> <TabItem value="php" label="PHP"> ```php file=./snippets/secrets/php/src/MyModule.php ``` </TabItem> <TabItem value="java" label="Java"> ```java file=./snippets/secrets/java/src/main/java/io/dagger/modules/mymodule/MyModule.java ``` </TabItem> </Tabs>The secret can be passed from the host environment via the env provider:
Secrets can also be passed from host files via the file provider (shown below) or from host command output via the cmd provider:
Secrets can also be read from external secret managers, such as Vault (vault):
dagger call github-api --token=vault://credentials.github
Here is the same example, but using 1Password as the secret provider. The secret is passed from 1Password via the op provider. This requires the Dagger CLI to be authenticated with 1Password, which can be done by running op signin in the terminal.
dagger call github-api --token=op://infra/github/credential
Secrets can also be read from AWS Secrets Manager and AWS Systems Manager Parameter Store using the aws provider. The provider automatically detects which service to use based on the path format.
Use the aws+sm:// scheme with a secret name to retrieve secrets from AWS Secrets Manager:
dagger call github-api --token=aws+sm://prod/github/token
For JSON secrets, extract a specific field using the field query parameter:
dagger call database --password=aws+sm://prod/database/credentials?field=password
Additional query parameters:
region: Override the default AWS region (e.g., aws+sm://my-secret?region=us-west-2)version: Retrieve a specific version by version ID (e.g., aws+sm://my-secret?version=uuid-version-id)stage: Retrieve a specific version stage (e.g., aws+sm://my-secret?stage=AWSPREVIOUS)Use the aws+ps:// scheme with a path starting with / to retrieve parameters from Parameter Store:
dagger call app --api-key=aws+ps:///prod/api-key
SecureString parameters are automatically decrypted.
The AWS provider uses the AWS SDK default credential chain, which checks for credentials in the following order:
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)~/.aws/credentials)Configure the default region using the AWS_REGION environment variable or the region query parameter.
:::note The AWS provider only reads secrets from AWS services. Secret creation and management should be done using the AWS CLI, AWS Console, or infrastructure-as-code tools like Terraform or CloudFormation. :::