Skip to main content

Security

Dagger is secure by design. All Dagger Functions are fully "sandboxed" and do not have direct access to the host system. Dagger also natively supports reading secrets from multiple secret providers and has built-in safeguards to ensure that secrets do not leak into the open.

Sandboxing

Dagger is built to protect your host environment by default. This means that Dagger Functions cannot access host resources - such as the host environment, host services, host filesystem, or host SSH agent - unless you explicitly grant permission by passing them as arguments.

Dagger’s security model treats the top-level module (i.e., the main function or highest-level call) as the single place where sensitive resources are introduced. It is only through this call that a user can explicitly provide directories, services, sockets, or secrets. In turn, the top-level module may pass these resources to other installed modules if needed, but there is never any implicit sharing.

important

By requiring typed arguments such as Directory, Socket, Service, or Secret, Dagger ensures users understand exactly what they are sharing with a Dagger Function. This explicit access design helps prevent malicious or untrusted modules from inadvertently obtaining sensitive data.

Secrets

Dagger also natively supports the use of confidential information ("secrets") such as passwords, API keys, SSH keys, and access tokens. 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 and Vault.

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:

package main

import (
"context"
"dagger/my-module/internal/dagger"
)

type MyModule struct{}

func (m *MyModule) GithubApi(
ctx context.Context,
token *dagger.Secret,
) (string, error) {
return dag.Container().
From("alpine:3.17").
WithSecretVariable("GITHUB_API_TOKEN", token).
WithExec([]string{"apk", "add", "curl"}).
WithExec([]string{"sh", "-c", `curl "https://api.github.com/repos/dagger/dagger/issues" --header "Accept: application/vnd.github+json" --header "Authorization: Bearer $GITHUB_API_TOKEN"`}).
Stdout(ctx)
}

Host environment

The secret can be passed from the host environment via the env provider:

Files

Secrets can also be passed from host files via the file provider (shown below) or from host command output via the cmd provider:

Hashicorp Vault and 1Password

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

Learn more