Heimdall.conf


The file is a configuration file and can be used to populate environmental variables or cloud environments. It should be generated at directory: /etc/heimdall.conf

It can contain different options which should be echoed out if necessary with syntax: "${optionName}=${optionValue}":

Heimdall Environmental Variables

Main Options Description
hdRole It can be used to control if this environment is the server (central manager) or the proxy. If empty, it works as server and allows to create "local" or "run as service" proxies.
Note, if the hdRole is set, then the instance will automatically allocate 80% of instance memory for the process (server or proxy).
javaOptions Any arbitrary options desired to be set for the java process.
hdHost Hostname of management server
hdPort Port of the management server (generally 8087 or 8443)
secure If the connection should be HTTPS or HTTP

| (hdRole=server) Options | Description | |:-----------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | hdUser | Server login username (by default, admin) | | hdPassword | Server login password (by default, heimdall) | | hdSecretKey |

In AWS, use this as the name of an "AWS Secret" to store the configuration, protecting included passwords from being written to disk. To use, proper permissions must be set on the IAM role. This option provides two major benefits. First is that all passwords are stored in AWS Secrets, in an encrypted format. Second is that redeployment of a management server can be done with a configuration pre-populated, so there is no need to backup and restore configurations to account for failures. Simply terminate the old instance and a new instance with the same user-data will be created with the same configuration as the original.
| | cloudDetection | If the manager should detect cloud services on startup | | cloudOptions | (Available when cloud Detection is disabled)
For heimdall running on premise to allow using cloud services, initializes on startup
(none, aws, azure, gcp, oracle) |

Example script for server:

#!/bin/bash
(
echo "hdRole=server"
echo "hdHost=localhost"
echo "hdPort=8443"
echo "hdUser=admin"
echo "hdPassword=heimdall"
echo "cloudDetection=true"
echo "cloudDetection=aws"
echo "secure=true"
) > /etc/heimdall.conf

Example script for proxy:

(hdRole=proxy) Options Description
hdUser Proxy login username. To successful auth, it must be consistent with the Access Key of the vdb with the defined vdbName.
hdPassword Proxy login password. To successful auth, it must be consistent with the Secret Key of the vdb with the defined vdbName.
vdbName Exact name of the vdb that we want to auth to. 
#!/bin/bash
(
echo "hdHost=localhost"
echo "hdPort=8443"
echo "hdUser=correct_access_key"
echo "hdPassword=correct_secret_key"
echo "vdbName=the_vdb"
echo "secure=true"
) > /etc/heimdall.conf

Secrets Environmental Variables

The Proxy can authenticate to the Central Manager via secrets. Below environmental variables can be set instead of hdUser and hdPassword when VDB is configured with Access/Secret Keys. An optional way to set this value is to enter an "hdUser" field starting with "secret:" and the name of the secret. This will only override the secret name if it is otherwise blank. Most of those variables will be automatically set via using secrets checkbox in the Config Management section of Admin tab.

Secrets Option Name Description
useSecretForVdbCredentials If the VDB will use secret for Access/Secret keys. Available options: true, false.
vdbCredentialsSecretName A VDB access and secret keys will be fetched from the Secrets Manager using this value.
secretsManagerConfigName Name of the Secrets Manager Config. If you are setting it manually, it can be random name.
secretsManagerType Type of the Secrets Manager Config. Available options: AWS, CYBERARK_CONJUR, HASHICORP_VAULT.

The specific environmental variables for HashiCorp Vault Secrets Manager.

HashiCorp Vault Option Name Description
VAULT_ADDR The URL of the Hashicorp Vault instance.
VAULT_TOKEN Token used for authentication. It should have permissions appropriate to access deserved secret values.

The specific environmental variables for CyberArk Conjur Secrets Manager.

CyberArk Conjur Option Name Description
CONJUR_APPLIANCE_URL The URL of the Conjur instance you are connecting to. When connecting to Conjur Enterprise configured for high availability, this should be the URL of the master load balancer (if performing read and write operations) or the URL of a follower load balancer (if performing read-only operations).
CONJUR_ACCOUNT Conjur account that you are connecting to. This value is set during Conjur deployment.
CONJUR_AUTHN_LOGIN User/host identity.
CONJUR_AUTHN_API_KEY User/host API key (or password).
CONJUR_AUTHN_URL (optional) Alternate authentication endpoint. By default, the client uses the standard <applianceUrl>/authn for generic username and API key login flow.

For example, if you want to use CyberArk Conjur as a Secrets Manager manually.

#!/bin/bash
(
...
the above main options without hdUser & hdPassword...
...
echo "useSecretForVdbCredentials=true"
echo "vdbCredentialsSecretName=Test/secret"
echo "secretsManagerConfigName=random_name"
echo "secretsManagerType=CYBERARK_CONJUR"
echo "CONJUR_APPLIANCE_URL=<your-appliance-url>"
echo "CONJUR_ACCOUNT=<your-account>"
echo "CONJUR_AUTHN_LOGIN=<your-authn-login>"
echo "CONJUR_AUTHN_API_KEY=<your-api-key>"
) > /etc/heimdall.conf
Once initialized, this configuration can be adjusted manually in the /etc/heimdall.conf if necessary. These settings will effectively allow auto-scaling groups of proxies to be configured.


Please note: If building an AMI for auto-scaling, which may be used by multiple scaling groups with different configurations, it is suggested that after doing initial testing, the heimdall.conf be deleted so that user-data will be re-read to build the Heimdall configuration. This will leverage the user-data on each new initialization to build the configuration at startup.