Vault Agent Auto Auth and Token Sink

Legacy applications often lack built-in support for Vault authentication. By deploying a Vault Agent alongside each application server, you can offload authentication, token renewal, and secure token storage to the Agent. The application simply reads a local “sink” file to obtain a valid Vault token and perform secret operations.

Legacy Application Auto-Auth Workflow

1. Vault Agent authenticates to Vault using a machine-oriented auth method (e.g., AppRole, Kubernetes).
2. Vault returns a token, which the Agent writes to a local sink file.
3. The legacy application reads the token from the sink and calls the Vault API for secret operations (read secrets, encrypt/decrypt).

The Vault Agent also tracks token TTL and automatically renews the token before expiration, ensuring the application always has a valid credential.

How Auto-Auth Works

Vault Agent’s auto-auth feature is configured in a single HCL file. It authenticates using the specified method, writes the returned token to a flat file sink, and then handles reauthentication and renewal automatically.

Supported Auth Methods

The Vault Agent supports all machine-oriented auth methods:

Example: AppRole Auto-Auth Configuration

Below is a minimal HCL configuration for AppRole authentication, writing the token to a file sink:

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"
  }
}

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

Sink Configuration

Vault Agent currently supports only the file sink type. Common parameters:

• type (always file)
• path (location for the token file)
• mode (file permissions, default 0640)
• wrap_ttl (optional response-wrapping TTL)

Response Wrapping for Enhanced Security

To protect tokens in transit or at the host, Vault offers a response-wrapping feature. You can apply wrapping at either the auth method or the sink.

1. Wrap at the Auth Method

When you set wrap_ttl under the auth method, Vault returns a single-use wrapped token reference. This prevents eavesdropping on the actual token but means the Agent cannot renew it.

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    wrap_ttl   = "5m"         # wrap at auth method
    config = {
      role = "example-role"
    }
  }
}

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

2. Wrap at the Sink

By setting wrap_ttl under the sink stanza, the Agent unwraps the Vault response and rewraps it for the application. The Agent can still renew the token, but the token travels in cleartext between Vault and the Agent.

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    config = {
      role = "example-role"
    }
  }
}

sink "file" {
  wrap_ttl = "5m"            # wrap at sink
  config = {
    path = "/etc/vault/token"
  }
}

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

Comparison of Wrapping Options

Conclusion

Vault Agent’s Auto-Auth and Token Sink features simplify secret injection for legacy applications by centralizing authentication, renewal, and local storage of Vault tokens. Response wrapping further enhances security according to your threat model.

Links and References

• Vault Agent Auto-Auth Documentation
• Vault Response Wrapping
• HashiCorp Vault: AppRole Auth Method
• Kubernetes Authentication