Secrets Management — 7 Providers in Xferity Secure MFT

Secrets Management

Xferity uses a secret reference system. Instead of specifying credential values directly in YAML configuration, you specify a reference that Xferity resolves at runtime.

No password, API key, or passphrase needs to ever appear in a config file. When security.hardened_mode: true, plaintext secrets in any config file cause startup to fail.

Quick reference

Provider	Ref format	Example
Environment variable	env:VAR_NAME	env:SFTP_PASSWORD
File	file:/path/to/secret	file:/run/secrets/sftp_pass
Literal (for testing only)	literal:value	literal:test123
Local vault (AES-256)	local-vault:key-name	local-vault:vendor-a-sftp
HashiCorp Vault	vault:path#field	vault:secret/data/mft/sftp#password
AWS Secrets Manager	aws-sm:secret-id#field	aws-sm:prod/mft/vendor_a#password
Azure Key Vault	azure-kv:secret-name	azure-kv:mft-vendor-a-password

Where to use secret references

Secret references can be used anywhere a credential appears in configuration:

# SFTP partner password
password: env:VENDOR_A_SFTP_PASSWORD

# SSH key passphrase
key_passphrase: file:/run/secrets/vendor_a_key_pass

# PGP private key passphrase (in flow config)
pgp:
  passphrase: vault:secret/data/mft/pgp#passphrase

# Database password
state:
  postgres:
    password: env:XFERITY_DB_PASSWORD

# Auth password
auth:
  local:
    password_ref: local-vault:xferity-admin-password

# Notification webhook secret
notifications:
  webhook:
    secret: aws-sm:prod/mft/webhook#hmac_key

Provider: Environment variable

Reference format: env:VAR_NAME

Reads the value from the named environment variable.

password: env:SFTP_PASSWORD

export SFTP_PASSWORD="my-secret-password"
xferity run my-flow

Or use --env-file to load variables from a file without polluting the shell environment:

xferity run my-flow --env-file /run/secrets/xferity.env

Provider: File

Reference format: file:/absolute/path/to/secret

Reads the file and uses its trimmed content as the secret value. The file path must be absolute.

password: file:/run/secrets/vendor_a_sftp_password
key_passphrase: file:/etc/xferity/keys/pgp_passphrase

Suitable for Docker secrets (/run/secrets/), Kubernetes secrets mounted as volumes, or any secret management system that writes to files.

Provider: Local vault (AES-256)

Reference format: local-vault:key-name

Reads from Xferity’s built-in encrypted local vault. The vault stores secrets encrypted with AES-256 and is suitable for deployments that need an encrypted at-rest secrets store without an external dependency.

password: local-vault:vendor-a-sftp-password

Configuring the local vault

secrets:
  local_vault:
    master_key_ref: env:MFT_MASTER_KEY  # or file:/run/secrets/master_key

The master key must be a cryptographically random base64-encoded 32-byte key.

Seeding secrets into the vault

# Generate a master key
openssl rand -base64 32

# Set the master key and seed secrets
MFT_MASTER_KEY=<your-base64-key> xferity vault seed

The vault is managed via the web UI (Secrets page) or the API. Secrets are never shown in plaintext after creation.

Provider: HashiCorp Vault

Reference format: vault:path#field

Reads a field from a HashiCorp Vault KV v2 secret.

password: vault:secret/data/mft/vendor_a#password
key_passphrase: vault:secret/data/mft/pgp_keys#passphrase

Configuration

secrets:
  vault:
    address: https://vault.example.com:8200
    token_ref: env:VAULT_TOKEN          # or file:/run/secrets/vault_token
    namespace: ""                        # leave empty for Vault OSS
    tls:
      ca_cert_ref: file:/etc/ssl/vault-ca.pem
      insecure_skip_verify: false        # NEVER true in hardened mode

Only KV v2 is supported. The path format is secret/data/<path>#<field>.

For Vault Enterprise, set namespace to your namespace path.

For Vault Agent or Vault Proxy, set address to the agent socket URL and omit token_ref.

Provider: AWS Secrets Manager

Reference format: aws-sm:secret-id or aws-sm:secret-id#field

Reads a secret from AWS Secrets Manager. If the secret is a JSON object, #field extracts a specific key.

password: aws-sm:prod/mft/vendor_a#password
api_key:  aws-sm:prod/mft/api_credentials#sendgrid_api_key

Configuration

secrets:
  aws:
    region: us-east-1
    use_default_chain: true  # recommended — uses IAM role, env vars, etc.
    # Optional explicit credentials (for environments without IAM):
    # access_key_id_ref: env:AWS_ACCESS_KEY_ID
    # secret_access_key_ref: env:AWS_SECRET_ACCESS_KEY
    # For LocalStack or VPC endpoints:
    # endpoint_url: http://localhost:4566

When use_default_chain: true, Xferity uses the standard AWS SDK credential chain:

1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. Shared credentials file (~/.aws/credentials)
3. EC2 Instance Metadata Service (IMDS) — for EC2/ECS/EKS
4. Container credential provider — for Fargate

This is the recommended approach for deployments on AWS infrastructure.

Provider: Azure Key Vault

Reference format: azure-kv:secret-name or azure-kv:secret-name/version

Reads a secret from Azure Key Vault.

password: azure-kv:vendor-a-sftp-password
api_key:  azure-kv:sendgrid-api-key/abc1234567890abcdef1234567890abcd

Configuration

secrets:
  azure_kv:
    vault_url: https://my-vault.vault.azure.net
    use_default_credential: true  # recommended — uses Managed Identity, etc.
    # Optional explicit service principal:
    # tenant_id_ref: env:AZURE_TENANT_ID
    # client_id_ref: env:AZURE_CLIENT_ID
    # client_secret_ref: env:AZURE_CLIENT_SECRET

When use_default_credential: true, Xferity uses the Azure SDK DefaultAzureCredential chain:

1. Environment variables (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET)
2. Workload identity (AKS)
3. Managed Identity (Azure VMs, App Service, Container Apps)
4. Azure CLI (for local development)

This is the recommended approach for deployments on Azure infrastructure.

Provider: Literal (testing only)

Reference format: literal:value

Uses the literal string as the secret value. This is for testing only. In hardened mode, literal references to passwords and tokens are not allowed (they expose the secret in config files).

password: literal:test-password-do-not-use-in-production

Secret caching

Resolved secret values are cached in memory to avoid repeated external calls. The cache is populated on startup and refreshed when Xferity detects a configuration reload.

To force a refresh of a cached secret, restart the Xferity process or use xferity operator reload-secrets.

Redaction in logs

Xferity automatically suppresses secret values from all log output and audit events. The following key patterns trigger redaction:

• password, passphrase
• private_key, privatekey
• secret, token, api_key, apikey

When any of these appear in log context, the value is replaced with [REDACTED].

In security.hardened_mode: true, Xferity also enforces redaction at config load time — any of these keys with literal values cause startup to fail.

Multiple providers in one deployment

There is no limit on combining providers. A typical production deployment might use:

secrets:
  local_vault:
    master_key_ref: env:MFT_MASTER_KEY     # vault for most secrets

  vault:
    address: https://vault.corp.example    # Vault for high-value keys

  aws:
    region: us-east-1
    use_default_chain: true               # AWS SM for S3 credentials

# Partner config using different providers:
sftp:
  password: local-vault:vendor-a-sftp       # low-sensitivity
  key_passphrase: vault:secret/data/mft#kp  # high-sensitivity

See Also

• Hardened Mode
• HashiCorp Vault Integration
• AWS Secrets Manager Integration
• Azure Key Vault Integration
• CLI Reference — vault seed