Choose the encryption trust boundary

X2 remains functional without KMI for evaluation. Production credentials and object data should use an explicitly configured provider whose authorization and unseal material remain outside X2 consensus.

Command platform

Linux

Decision guide

Select a provider before storing production data

The session-signing and credential key names are stable internal identities. Bucket default encryption uses the cluster default object key unless an administrator selects a separately created customer key.

Supported

X2 KMS

Operate a sealed, independently authorized KMS cluster. X2 Node authenticates with a pinned client public-key identity and exact grants.

Manual initialization and unseal
Root-token operator administration
Per-node workload identities
Signing and data-key operations

Open X2 KMS guide

Supported

HashiCorp Vault

Use Vault Transit with AppRole, token-file, or client-certificate authentication and least-privilege policies.

Existing Vault operations model
Transit signing and envelope protection
Node-local provider credentials

Configure Vault

Adapter required

Cloud providers

AWS KMS, Azure Key Vault, and Google Cloud KMS require dedicated KMI adapters and workload-identity mappings. Unsupported provider names fail closed.

Review provider status

Security model

What stays outside X2

Operator authority

KMS root tokens, unseal shares, Vault root credentials, and cloud administrative identities never enter X2 configuration or UI.

Node authority

Each node receives its own provider workload identity. Copying one client certificate or private key to every node is prohibited.

Stored state

Provider credentials and private keys remain under the node secrets root. Consensus stores references and encrypted envelopes, not master keys.

HashiCorp Vault

Connect Vault Transit

Create a dedicated Transit mount and role with only the signing and data-key operations X2 requires.

Linux environment

export X2_KMI_ENABLED=true
export X2_KMI_PROVIDER=hashicorp-vault
export X2_VAULT_ADDRESS=https://vault.example.com:8200
export X2_VAULT_TRANSIT_MOUNT=transit
export X2_VAULT_AUTH_METHOD=approle
export X2_VAULT_ROLE_ID_FILE=/var/lib/x2/secrets/vault-role-id
export X2_VAULT_SECRET_ID_FILE=/var/lib/x2/secrets/vault-secret-id
export X2_VAULT_CA=/var/lib/x2/secrets/vault-ca.crt

Windows environment

$env:X2_KMI_ENABLED='true'
$env:X2_KMI_PROVIDER='hashicorp-vault'
$env:X2_VAULT_ADDRESS='https://vault.example.com:8200'
$env:X2_VAULT_TRANSIT_MOUNT='transit'
$env:X2_VAULT_AUTH_METHOD='approle'
$env:X2_VAULT_ROLE_ID_FILE='C:\ProgramData\X2\secrets\vault-role-id'
$env:X2_VAULT_SECRET_ID_FILE='C:\ProgramData\X2\secrets\vault-secret-id'
$env:X2_VAULT_CA='C:\ProgramData\X2\secrets\vault-ca.crt'

macOS configuration

sudo /usr/local/lib/x2/x2-node configure \
  --kmi-enabled --kmi-provider hashicorp-vault \
  --vault-address https://vault.example.com:8200 \
  --vault-transit-mount transit --vault-auth-method approle \
  --vault-role-id-file /usr/local/var/lib/x2/state/secrets/vault-role-id \
  --vault-secret-id-file /usr/local/var/lib/x2/state/secrets/vault-secret-id \
  --vault-ca /usr/local/var/lib/x2/state/secrets/vault-ca.crt

Credential handling: do not place tokens, Secret IDs, client private keys, or unseal material in node.yaml, consensus, the UI, or release manifests.

Provider status

KMI adapter support

Provider	Status	Identity	Operations
X2 KMS	Supported	Pinned client public-key ID	Sign and data-key transit
HashiCorp Vault	Supported	Token, AppRole, or certificate	Transit sign/encrypt/decrypt
AWS KMS	Adapter required	Workload IAM role	Sign, GetPublicKey, GenerateDataKey, Decrypt
Azure Key Vault	Adapter required	Managed identity	Sign and wrap/unwrap
Google Cloud KMS	Adapter required	Workload identity	Sign and envelope protection