AWS Control Tower
Last updated
Was this helpful?
Last updated
Was this helpful?
Hava can be integrated with AWS Control Tower to automatically manage the Sources registered in Hava as AWS Accounts are added or removed using the account vending machine. This makes the process of managing AWS Sources in Hava fully automatic and hands-off.
The integration is based around a lambda that is executed on specific events in Control Tower and is also run as a schedule. It will connect to each account in the organisation using the control tower admin role and configure a read only role for Hava, and then register the role with Hava.
Hava then uses AWS Cross Account Role access to connect to the registered account and import metadata about the resources deployed in the account.
The integration can be found in our GitHub organization here:
It contains the lambda, as well as a Terraform template to deploy all the required resources.
Access to the base organization account
Terraform CLI
Hava Teams account with an API token
Hava API token stored in AWS Systems Manager Parameter Store
The recommended approach to deploying this integration is to use the provided Terraform template, as it will deploy all the required resources and have been tested to work across multiple different organisations.
Start by either downloading or cloning the repository to get a full copy of all the files on your local system, or where you will be deploying the template from.
There are a few configuration values that needs to be set up for the template to deploy successfully. Create a terraform.tfvars file inside the Terraform directory and add the following values.
hava_external_id is the unique external id for your Hava account. This is used for security purposes to make sure the AWS roles generated for Hava can only be used by Hava. This can be found on the "add source" modal in the Hava UI.
hava_token_path is the path to the API token in AWS Systems Manager Parameter store. This is a secure way to store the API token without having to pass this through insecure channels or store this in the Terraform state file.
hava_dry_run is used to enable dry run mode, and set the integration to write changes to the logs, but not execute any changes against either Hava nor AWS APIs. We leave this as true to begin with while we test.
Use the Terraform CLI to initialise and apply the changes to the AWS Organization rool account from the terraform directory.
Once the terraform apply is complete, open the AWS Console and locate the deployed Lambda. By default it will be called hava-integration.
Use the console to run a test with no input. This should execute the lambda in dry-run mode and allow you to verify that everything is running as expected by checking the logs.
Once tests confirm everything is running as expected update the terraform.tfvars file with hava_dry_run=false and apply the changes.
Now that everything is deployed, manually trigger the integration by running the test like in step 4. This will go through a full synchronization of all accounts in the organization and start building the diagrams for each in Hava.
The external id parameter is used together with the Hava AWS Account id to ensure that only Hava can access this role.
More details on the configuration values can be found in the readme for the Terraform template:
To allow certain OUs or accounts to be ignored by the integration, there is a block list for OUs and account IDs. Details on how to configure this can be found in .
This integration creates a role in each AWS Account in the organization with the AWS Managed policy ReadOnlyAccess. Details on this role can be found in the .
