Vault Agent Auto Auth and Token Sink

Enable legacy applications to consume Vault secrets without embedding Vault client logic. Vault Agent runs as a sidecar or local daemon to handle authentication, token management, caching, and templating on behalf of your app.

What Is Vault Agent?

Vault Agent is a lightweight client-side daemon designed to:

• Automatic Authentication & Renewal – Offload login and token refresh.
• Secure Token Storage – Persist tokens via configurable sinks.
• Local Secret Caching – Reduce Vault server load and latency.
• Templating – Render config files or environment variables from Vault data.

This pattern is ideal for legacy workloads that can’t natively integrate with Vault’s auth backends.

Integrating Legacy Applications

Deploy Vault Agent on the same host or pod as your application. The agent:

1. Authenticates to Vault using a chosen method (AppRole, Kubernetes, AWS, etc.).
2. Writes the token to a local sink (e.g., file).
3. Optionally renews the token and handles wraps.
4. Your app reads the token and invokes Vault’s HTTP API as usual.

Supported Authentication Methods

Choose the backend that matches your infrastructure:

Basic Vault Agent Configuration

Below is an example HCL file that configures AppRole auto-auth and a file-based token sink:

pid_file = "/home/vault/pidfile"

auto_auth {
  method "approle" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path   = "/etc/vault/role_id"
      secret_id_file_path = "/etc/vault/secret_id"
    }
  }
  sink "file" {
    config = {
      path = "/etc/vault/token.txt"
      # mode     = 640        # Optional POSIX permissions (default 640)
      # wrap_ttl = "5m"       # Optional: wrap response at sink
    }
  }
}

vault {
  address = "http://<cluster_ip>:8200"
}

• auto_auth: Defines how Vault Agent logs in.
• sink: Persists the Vault token (file sink supports auto-auth).
• vault.address: Points to your Vault cluster.

Securing Tokens with Response Wrapping

To reduce the risk of token interception (MITM), Vault supports response wrapping. You can wrap tokens at the auth method level or at the sink.

1. Wrapping at the Auth Method

Placing wrap_ttl under the method stanza causes Vault to return a single-use wrapped token reference. Vault Agent then unwraps it locally, but cannot renew it.

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    wrap_ttl   = "5m"
    config = {
      role = "example"
    }
  }
  sink "file" {
    config = {
      path = "/etc/vault/token.txt"
    }
  }
}

vault {
  address = "http://<cluster_ip>:8200"
}

Pros:

• No raw token travels over the network.

Cons:

• Vault Agent cannot renew the token (wrapped tokens are single-use).

2. Wrapping at the Sink

If you put wrap_ttl under the sink, Vault Agent first obtains the raw token, wraps it locally, and then writes the wrapped token to disk. Renewal remains functional, but the token is exposed in transit.

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    config = {
      role = "example"
    }
  }
  sink "file" {
    wrap_ttl = "5m"
    config = {
      path = "/etc/vault/token.txt"
    }
  }
}

vault {
  address = "http://<cluster_ip>:8200"
}

Pros:

• Token renewal works automatically.

Cons:

• Raw token travels unwrapped over the network.

3. Wrapping Method Comparison

Summary

• Vault Agent simplifies secret access for legacy applications by managing auth and tokens.
• Configure auto_auth and a file-based sink to centralize credentials.
• Use response wrapping to protect tokens—choose between auth-method wrapping (no transit exposure) or sink wrapping (supports renewal).

Next, explore Vault Agent’s templating and secret caching capabilities.

Links and References

• Vault Agent Auto-Auth Documentation
• Vault Response Wrapping
• HashiCorp Vault Official Docs