Containerized HPCC Systems Vault Secrets using appRole vault authentication
This example demonstrates HPCC use use of Hashicorp Vault secrets using appRole authentication.
This example assumes you are starting from a linux command shell in the HPCC-Platform/helm directory. From there you will find the example files and this README file in the examples/secrets directory.
Hashicorp Vault support:
This example uses Hashicorp vault. The following steps can be used to set up a development mode only instance of vault just for the purposes of this example. This makes it easy to test out vault functionality without going through the much more extensive configuration process for a production ready vault installation.
Install hashicorp vault command line client on your local system:
https://learn.hashicorp.com/tutorials/vault/getting-started-install
Install hashicorp vault service in dev mode:
This is for development only, never deploy this way in production. Deploying in dev mode sets up an in memory kv store that won't persist secret values across restart, and the vault will automatically be unsealed.
In dev mode the default root token is simply the string "root".
Add Hashicorp helm repo:
helm repo add hashicorp https://helm.releases.hashicorp.comUpdate Helm repos.
helm repo updateInstall vault server.
Note that a recent change to the developer mode vault means that you have to set the VAULT_DEV_LISTEN_ADDRESS environment variable as shown in order to access the vault service from an external pod.
helm install vault hashicorp/vault --set "server.dev.enabled=true" --set 'server.extraEnvironmentVars.VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200'Setting up vault
Tell the vault command line application the server location (dev mode is http, default location is https)
export VAULT_ADDR=http://127.0.0.1:8200In a separate terminal window start vault port forwarding.
kubectl port-forward vault-0 8200:8200Login to the vault command line using the vault root token (development mode defaults to "root"):
vault login rootIf you don't provide the token on the command line you will be prompted to input the value and it will be hidden from view.
Configure vault appRole auth
Enabling appRole auth will allow access the vault via the appRole authentication protocol.
vault auth enable approleSetup vault auth policy granting access to the ecl secrets locations we plan to use:
vault policy write hpcc-kv-ro examples/secrets/hpcc_vault_policies.hclSetup hpcc-vault-access auth role:
vault write auth/approle/role/hpcc-vault-access \
token_policies="hpcc-kv-ro" \
secret_id_ttl= 768h \
token_num_uses=100 \
token_ttl=8h \
token_max_ttl=12h \
secret_id_num_uses=1000Fetch the RoleID of the AppRole:
vault read auth/approle/role/hpcc-vault-access/role-idOutput:
role_id <role_id>
Update values file
Edit examples/secrets/values-secrets-approle.yaml to set both appRoleId entries for the vault configurations to <role_id> output above.
Get a secret-id issued using the new role-id:
vault write -f auth/approle/role/hpcc-vault-access/secret-idOutput
secret_id <secret_id> secret_id_accessor <accessor> secret_id_ttl 10m
Create a kubernetes secret containing the secret_id that was just output.
kubectl create secret generic approle-secret --from-literal=secret-id=\<secret_id\>'eclUser' category secrets
Create example vault 'eclUser' secrets:
vault kv put secret/eclUser/vault-example crypt.key=@examples/secrets/crypt.key'ecl' category secrets
Secrets in the 'ecl' category are not accessible by ECL code directly and therefore not visible to ECL users. They can be used by internal ECL feartures and commands. For example:
HTTP-CONNECT Secrets:
This example focuses on ECL secrets to provide HTTP connection strings and credentials for ECL SOAPCALL and HTTPCALL commands.
These secrets are prefixed with the string "http-connect-" requiring this prefix ensures that HTTPCALL/SOAPCALL only accesses secrets which are intended for this use.
HTTP-CONNECT secrets consist of a url string and optional additional secrets associated with that URL. Requiring the url to be part of the secret prevents credentials from being easily hijacked via an HTTPCALL to an arbitrary location. Instead the credentials are explicitly associated with the provided url.
Besides the URL values can currently be set for proxy (trusted for keeping these secrets), username, and password.
Creating the HTTP-CONNECT Secrets
Create example vault secret:
Create example vault 'ecl' secrets:
vault kv put secret/ecl/http-connect-vaultsecret url=@examples/secrets/url-basic username=@examples/secrets/username password=@examples/secrets/passwordInstalling the HPCC with the secrets added to ECL components
Install the HPCC helm chart with the secrets just defined added to all components that run ECL.
helm install myhpcc hpcc/ --set global.image.version=latest -f examples/secrets/values-secrets-approle.yamlUse kubectl to check the status of the deployed pods. Wait until all pods are running before continuing.
kubectl get podsIf you don't already have the HPCC client tools installed please install them now:
https://hpccsystems.com/download#HPCC-Platform
Using the created 'eclUser' category secrets directly in ECL code
The following ecl command will run the example ECL file that demonstrates accessing a vault secret directly from ECL code.
ecl run hthor examples/secrets/crypto_vault_secret.eclThe expected result would be:
<Result>
<Dataset name='vault_message'>
<Row><vault_message>For your eyes only</vault_message></Row>
</Dataset>
</Result>Using the created 'ecl' category secrets via HTTPCALL from within ECL code
If you don't already have the HPCC client tools installed please install them now:
https://hpccsystems.com/download#HPCC-Platform
The following ecl command will run the example ECL file that demonstrates an HTTPCALL that uses a vault secret for connection and authentication.
ecl run hthor examples/secrets/httpcall_vault.eclFor each job the expected result would be:
<Result>
<Dataset name='Result 1'>
<Row><authenticated>true</authenticated></Row>
</Dataset>
</Result>