This terraform code builds an HCP Boundary enviroment that inclues connectivity to HCP Vault for credential brokering and injection, Okta integration for OIDC authentication and managed groups, and a number of AWS resources that are used as workers and Boundary targets.

This repo was built to run on Terraform Cloud or Enterprise. It uses the tfe_outputs data source to pass parameters from the init module to the build module. If you want to run this locally you will need to modify the code to use cross state sharing to populate those values. Additionally, you will need to update or remote the cloud provider block to match your Terraform configuration.

This repo consists of two modules:

boundary-demo-init - This module builds an HCP Boundary Cluster and HCP Vault Cluster along with an associated HVN for the Vault Cluster.
boundary-demo-eks - This module does the bulk of the work, building out all of the Boundary and Vault configuration as well as the AWS components used as workers and targets.

Notes

• If you do not wish to use the Okta integration you can simply rename or delete the okta.tf configuration file. All of the Okta related configuration is contained within the file and the terraform code should still build cleanly without it.
• The Okta group_ids that are mapped to the Okta app we create are currently hard coded so you will need to change those in the okta.tf file for the okta_app_group_assignment resources. I will look at turning this into a datasource or at least variables in the future.
• The Dynamic Host Set setup uses an IAM role and User configuration that is specific to Hashicorp Employee AWS sandbox accounts. If used in account without restrictions on the ability to create IAM users and policies then you will want to modify the configuration at the top of the boundary.tf config file to create the required IAM user and policy directly.

Set the variables to appropriate values and update the cloud block in the providers.tf files in each module as appropriate.
Init and apply the boundary-demo-init terraform first

boundary-demo-init % terraform init

boundary-demo-init % terraform apply -auto-approve

Once the boundary-demo-init run has completed init and apply the boundary-demo-eks terraform

boundary-demo-eks % terraform init

boundary-demo-eks % terraform apply -auto-approve

Notes:

• The terraform code is generally stable and completes in a single run but if you experience issues a second run is usually enough to correct them.
• If for some reason you need to rebuild the EC2 Boundary worker you should also taint the boundary_worker resource as rebuilding the EC2 instance without re-creating the worker in Boundary and getting a new auth key will cause the worker to fail to connect to the Boundary control plane.

If you are using the Okta integration then:

• Members of the dev_users group in Okta have permissions to connect to the targets in the dev_w2_project scope
• Members of the pie_users group in Okta have permissions to connect to the targets in the pie_w2_project scope
• Members of the it_users group in Okta have permissions to connect to the targets in the it_w2_project scope

boundary connect ssh -target-scope-name pie_w2_project -target-name pie-ssh-cert-target

boundary connect ssh -target-scope-name pie_w2_project -target-name pie-ssh-tcp-target -- -l ec2-user

You will still need credentials to connect to the EKS cluster via K8s, which you can get via the AWS CLI. Be sure to set the appropriate region where you deployed your AWS resources.

aws eks update-kubeconfig --name boundary-demo-cluster --region $AWS_REGION

boundary connect kube -target-scope-name pie_w2_project -target-name pie-k8s-target -- get pods

boundary connect postgres -target-scope-name dev_w2_project -target-name dev-db-target -dbname postgres

boundary connect rdp -exec bash -target-scope-name it_w2_project -target-name it-rdp-target -- -c "open rdp://full%20address=s={{boundary.addr}} && sleep 600"