Storing secrets in Vault [Technical Preview]

Store cluster credentials, SSH keys, and OAuth secrets in HashiCorp Vault instead of the CMA database so migration configuration files contain Vault paths and credentials are masked in the UI.

When Vault is enabled, CMA stores cluster credentials (Cloudera Manager passwords, SSH keys) as Vault KV v2 secrets. Configuration files generated during migration contain only Vault paths, not plaintext credentials. Credentials are masked in the CMA UI.

What is stored in Vault


Secret type	Vault path	Stored when
Cloudera Manager credentials	`secret/cma/clusters/<id>/cm`	Cluster registration
SSH keys	`secret/cma/clusters/<id>/ssh`	SSH credential configuration
Database passwords	`secret/cma/db`	CMA startup (when Vault is enabled)
OAuth2 client secrets	`secret/cma/auth`	CMA startup (when Vault is enabled)

When Vault is not configured, credentials are stored encrypted in the CMA database (H2 or PostgreSQL). The encryption key is derived from the database password.

Parcel deployment options

You can enable Vault using a Cloudera Manager-managed Vault service or by running the Vault binary bundled with the CMA parcel.

Option 1 — CM-managed Vault service: If the Vault CSD and parcel are deployed in Cloudera Manager, CMA can auto-detect the Vault service dependency.
1. Deploy the Vault parcel and add the Vault service in Cloudera Manager.
2. In CMA Master > Server > Configuration, set Vault Role ID (AppRole auth) and Vault Secret ID (AppRole auth).
3. Restart the CMA Master service.
Option 2 — External Vault using the bundled Vault binary: Use the Vault binary and scripts shipped with the CMA parcel on the CMA Server host.

Prerequisites: SSH (root) access to the CMA Server host; the CMA parcel is installed and activated; python3, wget, and unzip are available; outbound HTTPS access to releases.hashicorp.com for the Vault binary download.
1. SSH to the CMA Server host and install and start Vault.
```
export VAULT_HOME=/opt/cloudera/parcels/cma/vault-local
export SCRIPT_PATH=$VAULT_HOME/scripts/bin
export PYTHON_EXECUTABLE=python3

cd $VAULT_HOME/scripts/bin
bash vault-server.sh setup
bash vault-server.sh start
```
  By default, Vault listens on http://127.0.0.1:8210. Change the port with the VAULT_SERVER_PORT environment variable.
2. Configure AppRole authentication and note the role_id and secret_id values.
```
export VAULT_ADDR=http://127.0.0.1:8210
export VAULT_TOKEN=$(python3 -c "import json; print(json.load(open('$HOME/.vault_data/conf/.vault'))['root_token'])")

VAULT_BIN=/opt/cloudera/parcels/cma/vault-local/vault/vault

$VAULT_BIN auth enable approle

$VAULT_BIN policy write cma-policy - <<'EOF'
path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
EOF

$VAULT_BIN write auth/approle/role/cma-role \
  token_policies=cma-policy \
  token_ttl=1h \
  token_max_ttl=4h

$VAULT_BIN read auth/approle/role/cma-role/role-id
$VAULT_BIN write -f auth/approle/role/cma-role/secret-id
```
3. In CMA Master > Server > Configuration, set External Vault URL (for example http://127.0.0.1:8210), Vault Role ID (AppRole auth), and Vault Secret ID (AppRole auth).
4. Restart the CMA Master service from Cloudera Manager.

Verify that the vault profile is active on the CMA Server host:

grep 'profiles are active' /var/log/cma/cma-server.log | tail -1
grep 'vault-ext' /var/log/cma/cma-server.log | tail -1

The first command should list vault among active profiles. The second should show Loaded extension: vault-ext v1.0.0.

Managing Vault after setup

To restart Vault after a host reboot:

export VAULT_HOME=/opt/cloudera/parcels/cma/vault-local
export PYTHON_EXECUTABLE=python3
cd $VAULT_HOME/scripts/bin
bash vault-server.sh start

To stop Vault:

cd /opt/cloudera/parcels/cma/vault-local/scripts/bin
bash vault-server.sh stop

The Vault server runs as a background process. If the host reboots, restart Vault before starting CMA when the vault profile is active.

For Vault token file issues, see Vault Troubleshooting.