Dynamic host catalogs on AWS

The HCP Quickstart tutorials provide an overview of getting started with an HCP Boundary cluster.

If you have an HCP Boundary cluster deployed, the Access HCP Boundary tutorial provides an overview of configuring your local machine to authenticate with your HCP cluster.

This tutorial provides both CLI and UI workflows for setting up Dynamic updates to host catalogs on AWS.

Open a new terminal session and start Boundary in dev mode:

$ boundary dev
==> Boundary server configuration:

        [Controller] AEAD Key Bytes: 2auB8k/4H+FtMlOsmREyAhZF+UKSW/ON2WLZQOawg1E=
          [Recovery] AEAD Key Bytes: 6+i5uZzU7SVTSBrroNW5FhY/ZAMSdm3tjAOcZsY9ODs=
       [Worker-Auth] AEAD Key Bytes: yy/9yCfHJgZGy7/JzKDIL7jvlf52bupxtlKzW2V+sfg=
               [Recovery] AEAD Type: aes-gcm
                   [Root] AEAD Type: aes-gcm
            [Worker-Auth] AEAD Type: aes-gcm
                                Cgo: disabled
     Controller Public Cluster Addr: 127.0.0.1:9201
             Dev Database Container: condescending_khayyam
                   Dev Database Url: postgres://postgres:password@localhost:55011/boundary?sslmode=disable
         Generated Admin Login Name: admin
           Generated Admin Password: password
          Generated Host Catalog Id: hcst_1234567890
                  Generated Host Id: hst_1234567890
              Generated Host Set Id: hsst_1234567890
      Generated Oidc Auth Method Id: amoidc_1234567890
             Generated Org Scope Id: o_1234567890
  Generated Password Auth Method Id: ampw_1234567890
         Generated Project Scope Id: p_1234567890
                Generated Target Id: ttcp_1234567890
  Generated Unprivileged Login Name: user
    Generated Unprivileged Password: password
                         Listener 1: tcp (addr: "127.0.0.1:9200", cors_allowed_headers: "[]", cors_allowed_origins: "[*]", cors_enabled: "true", max_request_duration: "1m30s", purpose: "api")
                         Listener 2: tcp (addr: "127.0.0.1:9201", max_request_duration: "1m30s", purpose: "cluster")
                         Listener 3: tcp (addr: "127.0.0.1:9202", max_request_duration: "1m30s", purpose: "proxy")
                          Log Level: info
                              Mlock: supported: false, enabled: false
                            Version: Boundary v0.7.1
                        Version Sha: abd695e5bc42d01e4412bf6c76211c3fc93a93d7
           Worker Public Proxy Addr: 127.0.0.1:9202

==> Boundary server started! Log data will stream in below:

{
  "id": "uOgAddIzAL",
  "source": "https://hashicorp.com/boundary/dev-controller/boundary-dev",
  "specversion": "1.0",
  "type": "system",
  "data": {
    "version": "v0.1",
    "op": "worker.(Worker).createClientConn",
    "data": {
      "address": "127.0.0.1:9201",
      "msg": "connected to controller"
    }
  },
  "datacontentype": "text/plain",
  "time": "2021-11-18T21:16:10.726593-07:00"
}
{
  "id": "PWrgfVwa7O",
  "source": "https://hashicorp.com/boundary/dev-controller/boundary-dev",
  "specversion": "1.0",
  "type": "system",
  "data": {
    "version": "v0.1",
    "op": "controller.(interceptingListener).Accept",
    "data": {
      "msg": "worker successfully authed",
      "name": "dev-worker"
    }
  },
  "datacontentype": "text/plain",
  "time": "2021-11-18T21:16:10.746329-07:00"
}

Leave dev mode running in the current session, and open a new terminal window or tab to continue the tutorial.

If you intend on using Terraform to configure Boundary, copy the [Recovery] AEAD Key Bytes field from the output of boundary dev.

Ensure you are able to authenticate to Boundary as the admin user:

$ boundary authenticate
Please enter the login name (it will be hidden):
Please enter the password (it will be hidden):
Authentication information:
  Account ID:      acctpw_VOeNSFX8pQ
  Auth Method ID:  ampw_wxzojlKJLN
  Expiration Time: Mon, 13 Feb 2023 12:35:32 MST
  User ID:         u_1vUkf5fPs9
The token was successfully stored in the chosen keyring and is not displayed here.

This tutorial sets up permissions and hosts for host catalogs using the AWS CLI and CloudFormation.

There are four tasks necessary to set up hosts using the AWS CLI.

1. Deploy and tag the host set members appropriately
2. Configure user permissions for Boundary
3. Assign ec2:DescribeInstances IAM privileges to the configured IAM user (may be skipped)
4. Generate a Secret Access Key for the IAM user, enabling Boundary to authenticate and access the tagged hosts

First, ensure that the AWS CLI is configured correct with your account credentials. You will need the AWS Access Key, Secret Access Key, and (if needed) a Session Token.

Common ways to get set up include:

• Execute aws configure and pass the access values
• Export the access values as environment variables
• Configure the AWS credentials file

For more information on setting up the AWS CLI to interact with AWS, check the Configuring the AWS CLI documentation.

Create hosts

This tutorial deploys tagged hosts to test the dynamic host catalog integration.

To easily deploy a set of pre-configured hosts, a CloudFormation template file is available for use with AWS. CloudFormation is used to easily deploy the EC2 instances in this tutorial.

Clone down the sample template repository.

$ git clone https://github.com/hashicorp-education/learn-boundary-cloud-host-catalogs.git

Navigate into the aws directory.

$ cd learn-boundary-cloud-host-catalogs/aws/

The provided aws-dynamic-hosts.json template will be used to deploy a CloudFormation resource stack that contains the hosts to be included in our Boundary host catalog.

This tutorial uses the us-east-1a availability zone to deploy the EC2 instances, but you can use any region you want. To change the region, open the aws-dynamic-hosts.json file and update the AvailabilityZone.

Next, create a keypair to be used for the instances. Alternatively, you may open the aws-dynamic-hosts.json file and update the boundary-keypair to match the name of an existing EC2 keypair.

$ aws ec2 create-key-pair \
    --key-name boundary-keypair \
    --key-type rsa \
    --query "KeyMaterial" \
    --output text > boundary-keypair.pem

Ensure you are within the learn-boundary-cloud-host-catalogs/aws/ directory where the aws-dynamic-hosts.json file is located.

Deploy a new resource stack using the provided aws-dynamic-hosts.json template.

$ aws cloudformation create-stack \
  --stack-name boundary-dynamic-hosts \
  --template-body file://./aws-dynamic-hosts.json

Example output:

$ aws cloudformation create-stack \
  --stack-name boundary-dynamic-hosts \
  --template-body file://./aws-dynamic-hosts.json
{
    "StackId": "arn:aws:cloudformation:us-east-1:157470686136:stack/boundary-dynamic-hosts/c29af940-78b6-11ec-849d-12bc7613d5b9"
}

The deployment may take a few minutes.

Check that the stack was successfully created.

$ aws cloudformation list-stacks
{
    "StackSummaries": [
        {
            "StackId": "arn:aws:cloudformation:us-east-1:157470686136:stack/boundary-dynamic-hosts/da9ebb30-78a7-11ec-bb47-0eddcb3d6bf3",
            "StackName": "boundary-dynamic-hosts",
            "TemplateDescription": "AWS CloudFormation template for Boundary Dynamic Hosts tutorial. Deploying this template will incur costs to your AWS account.",
            "CreationTime": "2022-01-18T22:43:11.249000+00:00",
            "StackStatus": "CREATE_COMPLETE",
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

Lastly, verify that the hosts were successfully created by printing their "Name" tag using aws ec2 describe-instances. The following command will only print running instances, and will also report the availability zone and instance ID in table format.

$ aws ec2 describe-instances \
  --output table \
  --filters Name=instance-state-name,Values=running \
  --filters Name=tag-key,Values=Name \
  --query 'Reservations[*].Instances[*].{Instance:InstanceId,AZ:Placement.AvailabilityZone,Name:Tags[?Key==`Name`]|[0].Value}'

$ aws ec2 describe-instances \
  --output table \
  --filters Name=instance-state-name,Values=running \
  --filters Name=tag-key,Values=Name \
  --query 'Reservations[*].Instances[*].{Instance:InstanceId,AZ:Placement.AvailabilityZone,Name:Tags[?Key==`Name`]|[0].Value}'
----------------------------------------------------------------
|                       DescribeInstances                      |
+------------+-----------------------+-------------------------+
|     AZ     |       Instance        |          Name           |
+------------+-----------------------+-------------------------+
|  us-east-1a|  i-06f5a1240a2e0c3fb  |  boundary-3-production  |
|  us-east-1a|  i-0657b0de7662f9863  |  boundary-1-dev         |
|  us-east-1a|  i-0ac5cfcae66bdacf5  |  boundary-2-dev         |
|  us-east-1a|  i-0b6d3ad435c586783  |  boundary-4-production  |
+------------+-----------------------+-------------------------+

Configure an IAM user

Usually, you might configure an IAM user with the correct policies assigned for keeping the dynamic host catalog up-to-date. You may also use an existing IAM user and assign it the policy, or an IAM instance profile.

This tutorial demonstrates creating a new IAM user, but the tutorial can also be continued using root credentials. To continue using root credentials, skip to the Gather plugin details section.

Next, create a new IAM user for Boundary.

$ aws iam create-user --user-name boundary
{
    "User": {
        "Path": "/",
        "UserName": "boundary",
        "UserId": "AIDASWVU2XLZFFIP6P4IN",
        "Arn": "arn:aws:iam::157470686136:user/boundary",
        "CreateDate": "2022-01-12T19:35:32+00:00"
    }
}

Create a new file called boundary-describe-instances-policy.json, and fill it with the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

This policy allows the boundary IAM user to run the DescribeInstances API call, similar to running the aws ec2 describe-instances command using the CLI. Boundary will be able to list these details, including the host's tags. This will allow Boundary to sort hosts into their appropriate catalogs.

Next, attach this as an inline policy to the boundary user, giving it the name BoundaryDescribeInstances. This command assume the json policy file is located in the same directory the command is executed from.

$ aws iam put-user-policy \
  --user-name boundary \
  --policy-name BoundaryDescribeInstances \
  --policy-document file://./boundary-describe-instances-policy.json

Check your work by listing the policies attached to the user.

$ aws iam get-user-policy --user-name boundary --policy-name BoundaryDescribeInstances
{
    "UserName": "boundary",
    "PolicyName": "BoundaryDescribeInstances",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "ec2:DescribeInstances"
                ],
                "Effect": "Allow",
                "Resource": "*"
            }
        ]
    }
}

The last step is to create an access key for the user.

$ aws iam create-access-key --user-name boundary
{
    "AccessKey": {
        "UserName": "boundary",
        "AccessKeyId": "AKIASWVU2XLZLFLIDMVW",
        "Status": "Active",
        "SecretAccessKey": "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",
        "CreateDate": "2022-01-19T02:26:11+00:00"
    }
}

Keep the AccessKeyId and SecretAccessKey in a safe location for the remainder of this tutorial.

To get ready to configure Boundary, export these values as environment variables.

$ export BOUNDARY_ACCESS_KEY_ID=<AWS Access Key ID> \
  export BOUNDARY_SECRET_ACCESS_KEY=<AWS Secret Access Key>

Gather plugin details

To use the Boundary AWS hosts plugin, the following details must be available for a user that has access to the DescribeInstances API.

• AWS Access Key ID
• AWS Secret Access Key

These values should be available as environment variables within the terminal session, or copied to a safe location for use when setting up Boundary. This tutorial created the IAM user boundary and exported these values as environment variables.

$ export BOUNDARY_ACCESS_KEY_ID=<AWS Access Key ID> \
  export BOUNDARY_SECRET_ACCESS_KEY=<AWS Secret Access Key>

The prerequisites for setting up the learning environment with Terraform are:

1. Terraform 0.14.9 or greater or greater is installed
2. An active AWS account
3. The AWS CLI is installed and available in your PATH.

There are three tasks within AWS that Terraform needs to configure to set up the lab environment.

1. Deploy and tag the host set members appropriately
2. Configure user permissions for Boundary
3. Assign ec2:DescribeInstances IAM privileges to the configured IAM user
4. Generate a Secret Access Key for the IAM user, enabling Boundary to authenticate and access the tagged hosts

Configure Terraform and IAM user privileges

First, ensure that the CLI is properly configured and can contact your AWS account.

Export the account Access Key ID and Secret Access Key as environment variables for use by Terraform in the following steps. If you wish to change the region from us-east-1, change its value before export.

$ export AWS_ACCESS_KEY_ID=<Access Key ID> \
  export AWS_SECRET_ACCESS_KEY=<Secret Access Key> \
  export AWS_REGION=us-east-1

Execute the following command in your terminal to make sure your credentials are configured.

$ aws sts get-caller-identity
{
    "UserId": "AIDAWV7SJJRSWAD2Q32ES",
    "Account": "157470686136",
    "Arn": "arn:aws:iam::157470686136:user/username"
}

If the command does not return the correct user information, ensure the correct credentials have been exported in the terminal session.

Create a new working directory called learn-dynamic-host-catalogs and change into that directory. This tutorial assumes working out of the home directory ~/.

$ mkdir learn-dynamic-host-catalogs && cd learn-dynamic-host-catalogs/

Create a new file called main.tf and paste the following configuration.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

# Configure the AWS provider
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.73"
      }
  }
  required_version = ">= 0.14.9"
}

provider "aws" {
}

# Configure the AWS provider
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.73"
      }
  }
  required_version = ">= 0.14.9"
}

output "boundary_access_key_id" {
    value = aws_iam_access_key.boundary.id
}

output "boundary_secret_access_key" {
  value = aws_iam_access_key.boundary.secret
  sensitive = true
}

provider "aws" {
}

resource "aws_iam_user" "boundary" {
  name = "boundary"
  path = "/"
}

resource "aws_iam_access_key" "boundary" {
  user = aws_iam_user.boundary.name
}

resource "aws_iam_user_policy" "BoundaryDescribeInstances" {
  name = "BoundaryDescribeInstances"
  user = aws_iam_user.boundary.name
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
EOF
}

Now initialize the Terraform plan.

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/azurerm...
- Finding hashicorp/aws versions matching "~> 3.73"...

- Installing hashicorp/aws v3.73.0...
- Installed hashicorp/aws v3.73.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

After initialization, apply the plan and confirm by inputting yes when prompted.

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
  + create

Terraform will perform the following actions:

  # aws_iam_access_key.boundary will be created
  + resource "aws_iam_access_key" "boundary" {
      + create_date                    = (known after apply)
      + encrypted_secret               = (known after apply)
      + encrypted_ses_smtp_password_v4 = (known after apply)
      + id                             = (known after apply)
      + key_fingerprint                = (known after apply)
      + secret                         = (sensitive value)
      + ses_smtp_password_v4           = (sensitive value)
      + status                         = "Active"
      + user                           = "boundary"
    }

  # aws_iam_user.boundary will be created
  + resource "aws_iam_user" "boundary" {
      + arn           = (known after apply)
      + force_destroy = false
      + id            = (known after apply)
      + name          = "boundary"
      + path          = "/"
      + tags_all      = (known after apply)
      + unique_id     = (known after apply)
    }

  # aws_iam_user_policy.BoundaryDescribeInstances will be created
  + resource "aws_iam_user_policy" "BoundaryDescribeInstances" {
      + id     = (known after apply)
      + name   = "BoundaryDescribeInstances"
      + policy = jsonencode(
            {
              + Statement = [
                  + {
                      + Action   = [
                          + "ec2:DescribeInstances",
                        ]
                      + Effect   = "Allow"
                      + Resource = "*"
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + user   = "boundary"
    }

Plan: 3 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + boundary_access_key_id     = (known after apply)
  + boundary_secret_access_key = (sensitive value)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_iam_user.boundary: Creating...
aws_iam_user.boundary: Creation complete after 0s [id=boundary]
aws_iam_user_policy.BoundaryDescribeInstances: Creating...
aws_iam_access_key.boundary: Creating...
aws_iam_access_key.boundary: Creation complete after 0s [id=AKIASWVU2XLZOLN2IRD3]
aws_iam_user_policy.BoundaryDescribeInstances: Creation complete after 0s [id=boundary:BoundaryDescribeInstances]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

boundary_access_key_id = "AKIASWVU2XLZOLN2IRD3"
boundary_secret_access_key = <sensitive>

The Terraform run will output the boundary user's Access Key ID as the boundary_access_key_id, and the encrypted Secret Access Key as the boundary_secret_access_key. Terraform requires the protection of sensitive secret values, and will not print this value directly in the run output.

Copy the boundary_access_key_id (AKIASWVU2XLZOLN2IRD3 in this example) and export it as an environment variable.

$ export BOUNDARY_ACCESS_KEY_ID=<boundary_access_key_id>

If you have jq installed, run the following command to select the decrypted boundary_secret_access_key from the terraform.tfstate file and export it as an environment variable.

$ export BOUNDARY_SECRET_ACCESS_KEY=$(jq -r '.outputs.boundary_secret_access_key.value' terraform.tfstate)

If jq is not installed, open the terraform.tfstate file and locate the boundary_secret_access_key value and export it directly, like so:

$ export BOUNDARY_SECRET_ACCESS_KEY=<boundary_secret_access_key>

Check your work by ensuring the value is available within your shell session.

$ echo $BOUNDARY_SECRET_ACCESS_KEY
nm4Oph+Tlt7bss+z7RuYhqFaKSbkKEPDokv6hr9S

Create hosts

Next, a hosts.tf file is configured and deployed to test the dynamic host catalog integration.

Create a new Terraform configuration file called hosts.tf. Paste the following configuration in the new hosts file.

# Configure the AWS VM hosts

data "aws_availability_zones" "boundary" {}

resource "aws_vpc" "boundary_hosts_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name = "boundary_hosts_vpc"
  }
}

resource "aws_subnet" "boundary_hosts_subnet" {
  vpc_id                  = aws_vpc.boundary_hosts_vpc.id
  cidr_block              = aws_vpc.boundary_hosts_vpc.cidr_block
  availability_zone       = data.aws_availability_zones.boundary.names[0]
  map_public_ip_on_launch = true
  
  tags = {
    Name = "boundary_hosts_subnet"
  }
}

resource "aws_security_group" "boundary_ssh" {
  name        = "boundary_allow_ssh"
  description = "Allow SSH inbound traffic"
  vpc_id      = aws_vpc.boundary_hosts_vpc.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "allow_ssh"
  }
}

variable "instances" {
  default = [
    "boundary-1-dev", 
    "boundary-2-dev", 
    "boundary-3-production", 
    "boundary-4-production"
  ]
}

variable "vm_tags" {
  default = [
    {"Name":"boundary-1-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-2-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-3-production","service-type":"database", "application":"production"},
    {"Name":"boundary-4-production","service-type":"database", "application":"prod"}
  ]
}

resource "aws_instance" "boundary_instance" {
  count                  = length(var.instances)
  ami                    = "ami-083602cee93914c0c"
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.boundary_hosts_subnet.id
  vpc_security_group_ids = [aws_security_group.boundary_ssh.id]
  tags                   = var.vm_tags[count.index]
}

Save this file and run terraform apply again, confirming the new configuration by entering yes when prompted.

$ terraform apply

data.aws_availability_zones.boundary: Reading...
aws_iam_user.boundary: Refreshing state... [id=boundary]
aws_iam_user_policy.BoundaryDescribeInstances: Refreshing state... [id=boundary:BoundaryDescribeInstances]
aws_iam_access_key.boundary: Refreshing state... [id=AKIA3X2NGVVK2FXR66XH]
data.aws_availability_zones.boundary: Read complete after 0s [id=us-east-1]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.boundary_instance[0] will be created
  + resource "aws_instance" "boundary_instance" {
      + ami                                  = "ami-083602cee93914c0c"
      + arn                                  = (known after apply)
      + associate_public_ip_address          = (known after apply)
      + availability_zone                    = (known after apply)
      + cpu_core_count                       = (known after apply)
      + cpu_threads_per_core                 = (known after apply)
      + disable_api_termination              = (known after apply)
      + ebs_optimized                        = (known after apply)
      + get_password_data                    = false
      + host_id                              = (known after apply)
      + id                                   = (known after apply)
      + instance_initiated_shutdown_behavior = (known after apply)
      + instance_state                       = (known after apply)
      + instance_type                        = "t3.micro"
      + ipv6_address_count                   = (known after apply)
      + ipv6_addresses                       = (known after apply)
      + key_name                             = (known after apply)
      + monitoring                           = (known after apply)
      + outpost_arn                          = (known after apply)
      + password_data                        = (known after apply)
      + placement_group                      = (known after apply)
      + placement_partition_number           = (known after apply)
      + primary_network_interface_id         = (known after apply)
      + private_dns                          = (known after apply)
      + private_ip                           = (known after apply)
      + public_dns                           = (known after apply)
      + public_ip                            = (known after apply)
      + secondary_private_ips                = (known after apply)
      + security_groups                      = (known after apply)
      + source_dest_check                    = true
      + subnet_id                            = (known after apply)
      + tags                                 = {
          + "Name"         = "boundary-1-dev"
          + "application"  = "dev"
          + "service-type" = "database"
        }
      + tags_all                             = {
          + "Name"         = "boundary-1-dev"
          + "application"  = "dev"
          + "service-type" = "database"
        }
      + tenancy                              = (known after apply)
      + user_data                            = (known after apply)
      + user_data_base64                     = (known after apply)
      + vpc_security_group_ids               = (known after apply)
    }

  # aws_instance.boundary_instance[1] will be created
  + resource "aws_instance" "boundary_instance" {
      + ami                                  = "ami-083602cee93914c0c"
      + arn                                  = (known after apply)
      + associate_public_ip_address          = (known after apply)
      + availability_zone                    = (known after apply)
      + cpu_core_count                       = (known after apply)
      + cpu_threads_per_core                 = (known after apply)
      + disable_api_termination              = (known after apply)
      + ebs_optimized                        = (known after apply)
      + get_password_data                    = false
      + host_id                              = (known after apply)
      + id                                   = (known after apply)
      + instance_initiated_shutdown_behavior = (known after apply)
      + instance_state                       = (known after apply)
      + instance_type                        = "t3.micro"
      + ipv6_address_count                   = (known after apply)
      + ipv6_addresses                       = (known after apply)
      + key_name                             = (known after apply)
      + monitoring                           = (known after apply)
      + outpost_arn                          = (known after apply)
      + password_data                        = (known after apply)
      + placement_group                      = (known after apply)
      + placement_partition_number           = (known after apply)
      + primary_network_interface_id         = (known after apply)
      + private_dns                          = (known after apply)
      + private_ip                           = (known after apply)
      + public_dns                           = (known after apply)
      + public_ip                            = (known after apply)
      + secondary_private_ips                = (known after apply)
      + security_groups                      = (known after apply)
      + source_dest_check                    = true
      + subnet_id                            = (known after apply)
      + tags                                 = {
          + "Name"         = "boundary-2-dev"
          + "application"  = "dev"
          + "service-type" = "database"
        }
      + tags_all                             = {
          + "Name"         = "boundary-2-dev"
          + "application"  = "dev"
          + "service-type" = "database"
        }
      + tenancy                              = (known after apply)
      + user_data                            = (known after apply)
      + user_data_base64                     = (known after apply)
      + vpc_security_group_ids               = (known after apply)
    }

...
... Truncated Output ...
...

  # aws_vpc.boundary_hosts_vpc will be created
  + resource "aws_vpc" "boundary_hosts_vpc" {
      + arn                                  = (known after apply)
      + cidr_block                           = "10.0.0.0/16"
      + default_network_acl_id               = (known after apply)
      + default_route_table_id               = (known after apply)
      + default_security_group_id            = (known after apply)
      + dhcp_options_id                      = (known after apply)
      + enable_classiclink                   = (known after apply)
      + enable_classiclink_dns_support       = (known after apply)
      + enable_dns_hostnames                 = true
      + enable_dns_support                   = true
      + id                                   = (known after apply)
      + instance_tenancy                     = "default"
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      + main_route_table_id                  = (known after apply)
      + owner_id                             = (known after apply)
      + tags                                 = {
          + "Name" = "boundary_hosts_vpc"
        }
      + tags_all                             = {
          + "Name" = "boundary_hosts_vpc"
        }
    }

Plan: 7 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_vpc.boundary_hosts_vpc: Creating...
aws_vpc.boundary_hosts_vpc: Still creating... [10s elapsed]
aws_vpc.boundary_hosts_vpc: Creation complete after 14s [id=vpc-069ce0ae15adba350]
aws_subnet.boundary_hosts_subnet: Creating...
aws_security_group.boundary_ssh: Creating...
aws_security_group.boundary_ssh: Creation complete after 3s [id=sg-06f337d1052e1f7a5]
aws_subnet.boundary_hosts_subnet: Still creating... [10s elapsed]
aws_subnet.boundary_hosts_subnet: Creation complete after 12s [id=subnet-013951bb5195e3073]
aws_instance.boundary_instance[1]: Creating...
aws_instance.boundary_instance[3]: Creating...
aws_instance.boundary_instance[0]: Creating...
aws_instance.boundary_instance[2]: Creating...
aws_instance.boundary_instance[2]: Still creating... [10s elapsed]
aws_instance.boundary_instance[3]: Still creating... [10s elapsed]
aws_instance.boundary_instance[1]: Still creating... [10s elapsed]
aws_instance.boundary_instance[0]: Still creating... [10s elapsed]
aws_instance.boundary_instance[2]: Creation complete after 14s [id=i-04a8dd7b1831e6303]
aws_instance.boundary_instance[3]: Creation complete after 14s [id=i-0703a0432faa6a78b]
aws_instance.boundary_instance[0]: Creation complete after 14s [id=i-07d5db7b36b0c59c4]
aws_instance.boundary_instance[1]: Creation complete after 14s [id=i-0e6d4e1eb045eb46d]

Apply complete! Resources: 7 added, 0 changed, 0 destroyed.

Outputs:

boundary_access_key_id = "AKIASWVU2XLZOLN2IRD3"
boundary_secret_access_key = <sensitive>

Gather plugin details

To use the Boundary AWS hosts plugin, the following details must be available:

• AWS (Boundary user) Access Key ID
• AWS (Boundary user) Secret Access Key
• AWS Region

These values should be available as environment variables within the terminal session, or copied to a safe location for use when setting up Boundary.

Check that the values have been exported in your current shell session:

$ echo $BOUNDARY_ACCESS_KEY_ID; echo $BOUNDARY_SECRET_ACCESS_KEY; echo $AWS_REGION
AKIASWVU2XLZOLN2IRD3
aXe492h+rcr4jyhEWwc9FP+6XOiusDl4D8RarHP0
us-east-1

If these values are unavailable, see the previous sections on configuring Terraform users before proceeding.

This tutorial sets up permissions and hosts for host catalogs using the AWS Console and CloudFormation.

There are four tasks necessary to set up hosts using the AWS Console:

1. Deploy and tag the host set members appropriately
2. Configure user permissions for Boundary
3. Assign ec2:DescribeInstances IAM privileges to the configured IAM user (may be skipped)
4. Generate a Secret Access Key for the IAM user, enabling Boundary to authenticate and access the tagged hosts

Create hosts

This tutorial deploys tagged hosts to test the dynamic host catalog integration.

To easily deploy a set of pre-configured hosts, a CloudFormation template file is available for use with AWS. CloudFormation is used to easily deploy the EC2 instances in this tutorial.

Clone down the sample template repository.

$ git clone https://github.com/hashicorp-education/learn-boundary-cloud-host-catalogs.git

Navigate into the aws directory.

$ cd learn-boundary-cloud-host-catalogs/aws/

The provided aws-dynamic-hosts.json template will be used to deploy a CloudFormation resource stack that contains the hosts to be included in our Boundary host catalog.

This tutorial uses the us-east-1a availability zone to deploy the EC2 instances, but you can use any region you want. To change the region, open the aws-dynamic-hosts.json file and update the AvailabilityZone.

Next, create a keypair to be used for the instances. Alternatively, you may open the aws-dynamic-hosts.json file and update the boundary-keypair to match the name of an existing EC2 keypair.

Log into the AWS Console and navigate to the EC2 portal. Ensure that the us-east-1 region is selected.

Next, select Key Pairs from the Resources list or using the left-hand navigation bar under Network & Security.

Click Create key pair. Name the keypair boundary-keypair, leaving the type set to RSA and the file format set to .pem. Click Create key pair when finished.

The keypair will then be downloaded to your local machine.

Next, a set of sample hosts will be deployed using CloudFormation. You will need access to the location of the learn-boundary-cloud-host-catalogs repository downloaded earlier.

Navigate to the CloudFormation Portal by using the Search field.

Select Create stack.

From the Create Stack form, select Upload a template file from the Specify template section. Then click the Choose file button. Select the provided learn-boundary-cloud-host-catalogs/aws/aws-dynamic-hosts.json template file, then click Next.

Under the Specify stack details form, enter the Stack name boundary-dynamic-hosts. Under KeyName, select the boundary-keypair created earlier. The SSHLocation can be left as 0.0.0.0/0.

Leave the details on the Configure stack options page as-is, and click Next.

Confirm the stack details on the Review boundary-dynamic-hosts page, then scroll down and click Create stack.

The boundary-dynamic-hosts page will be displayed, with a list of Events. After a couple of minutes, press the Refresh button ⟳ until the Status shows CREATE_COMPLETE for each EC2Instance.

Configure an IAM user

Usually you might configure an IAM user with the correct policies assigned for keeping the dynamic host catalog up-to-date. You may also use an existing IAM user and assign it the policy, or an IAM instance profile.

First, define the policy that will be attached to the new user.

Navigate to the IAM Portal using the Search function.

Select Policies from the left-hand sidebar and click Create Policy.

Under the Create policy form, select the JSON tab.

Copy the following policy statement and paste it into the JSON editor.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

This policy allows the boundary IAM user to run the DescribeInstances API call, similar to running the aws ec2 describe-instances command using the CLI. Boundary will be able to list these details, including the host's tags. This will allow Boundary to sort hosts into their appropriate catalogs.

When finished, click Next: Tags.

Skip adding any tags and click Next: Review.

In the Review policy form, name the policy BoundaryDescribeInstances.

The Access level should be set as Limited: List and Resource should be set as All resources. If any of this is incorrect, click Previous and check that the JSON policy was copy-pasted correctly.

When finished, click Create policy.

The new policy should now be available under the Policies page.

Next, create a new IAM user for Boundary.

Select Users from the left-hand sidebar, then click Add users from the Users page.

In the Add user form, set the User name to boundary, and check the Access key - Programmatic access box. This will create an Access Key ID and Secret Access Key that Boundary can use to authenticate as the boundary user.

When finished, click the Next: Permissions button at the bottom of the page.

Click the Attach existing policies directly tab. Use the Search function and type "boundary" to locate the BoundaryDescribeInstances policy. Check the box next to the policy, then click Next: Tags.

Skip adding any tags and click Next: Review.

Review the new user details, ensuring that the AWS access type is defined as Programmatic access - with an access key. The Permissions summary should contain the Managed policy named BoundaryDescribeInstances.

When finished, click Create user.

Under the Success page, copy the boundary user credentials. Ensure that you copy both the Access key ID and the Secret access key by clicking the show button. You can also choose to click the Download .csv button instead, and copy the credentials from the downloaded file. These credentials cannot be accessed again, so ensure they are copied correctly from this page.

Keep the AccessKeyId and SecretAccessKey in a safe location for the remainder of this tutorial.

To get ready to configure Boundary, export these values as environment variables in a new terminal session.

$ export BOUNDARY_ACCESS_KEY_ID=<AWS Access Key ID> \
  export BOUNDARY_SECRET_ACCESS_KEY=<AWS Secret Access Key>

Gather plugin details

To use the Boundary AWS hosts plugin, the following details must be available for a user that has access to the DescribeInstances API.

• AWS Access Key ID
• AWS Secret Access Key

These values should be available as environment variables within the terminal session, or copied to a safe location for use when setting up Boundary. This tutorial created the IAM user boundary and exported these values as environment variables.

$ export BOUNDARY_ACCESS_KEY_ID=<AWS Access Key ID> \
  export BOUNDARY_SECRET_ACCESS_KEY=<AWS Secret Access Key>

Perform a read on the missing host.

$ boundary hosts read -id hplg_7KjFRrcLxD

Host information:
  Created Time:        Tue, 18 Jul 2023 10:37:22 MDT
  External ID:         i-08c588f2d58120192
  Host Catalog ID:     hcplg_Ia7R4E39oF
  ID:                  hplg_7KjFRrcLxD
  Type:                plugin
  Updated Time:        Tue, 18 Jul 2023 10:37:22 MDT
  Version:             1

  Scope:
    ID:                p_1234567890
    Name:              Generated project scope
    Parent Scope ID:   o_1234567890
    Type:              project

  Plugin:
    ID:                pl_1PRTDb78iY
    Name:              aws

  Authorized Actions:
    no-op
    read

  Host Set IDs:
    hsplg_qnQM03I6yT

  IP Addresses:
    172.31.71.39
    3.239.215.108

  DNS Names:
    ec2-3-239-215-108.compute-1.amazonaws.com
    ip-172-31-71-39.ec2.internal

The External ID: field shows the ID of the misconfigured host (i-08c588f2d58120192 in this example). Copy this value.

Recall that host set membership is defined based on the instance tags.

Describe the instance's details, and query for its tag values.

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

Sample output:

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

-------------------------------------------
|            DescribeInstances            |
+---------------+-------------------------+
|      Key      |          Value          |
+---------------+-------------------------+
|  service-type |  database               |
|  Name         |  boundary-4-production  |
|  application  |  prod                   |
+---------------+-------------------------+

Notice that the application tag is misconfigured as prod, instead of production. An easy mistake to make!

Remember the filter defined for the production host set:

tag:application=production

The tag's value must equal production exactly to be included in this host set.

Update the application tag to production for the misconfigured instance using the aws ec2 create-tags command, which will overwrite the existing tag value.

$ aws ec2 create-tags --resources i-08c588f2d58120192 --tags Key=application,Value=production

Re-run the describe-instances command to directly query for the updated tag values.

Sample output:

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

-------------------------------------------
|            DescribeInstances            |
+---------------+-------------------------+
|      Key      |          Value          |
+---------------+-------------------------+
|  application  |  production             |
|  service-type |  database               |
|  Name         |  boundary-4-production  |
+---------------+-------------------------+

Perform a read on the missing host.

$ boundary hosts read -id hplg_7KjFRrcLxD

Host information:
  Created Time:        Tue, 18 Jul 2023 10:41:34 MDT
  External ID:         i-08c588f2d58120192
  Host Catalog ID:     hcplg_Ia7R4E39oF
  ID:                  hplg_7KjFRrcLxD
  Type:                plugin
  Updated Time:        Tue, 18 Jul 2023 10:41:34 MDT
  Version:             1

  Scope:
    ID:                p_1234567890
    Name:              Generated project scope
    Parent Scope ID:   o_1234567890
    Type:              project

  Plugin:
    ID:                pl_1PRTDb78iY
    Name:              aws

  Authorized Actions:
    no-op
    read

  Host Set IDs:
    hsplg_qnQM03I6yT

  IP Addresses:
    172.31.71.39
    3.239.215.108

  DNS Names:
    ec2-3-239-215-108.compute-1.amazonaws.com
    ip-172-31-71-39.ec2.internal

The External ID: field shows the ID of the misconfigured host (i-08c588f2d58120192 in this example). Copy this value.

Recall that host set membership is defined based on the instance tags.

Describe the instance's details, and query for its tag values.

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

Sample output:

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

-------------------------------------------
|            DescribeInstances            |
+---------------+-------------------------+
|      Key      |          Value          |
+---------------+-------------------------+
|  service-type |  database               |
|  application  |  prod                   |
|  Name         |  boundary-4-production  |
+---------------+-------------------------+

Notice that the application tag is misconfigured as prod, instead of production. An easy mistake to make!

Remember the filter defined for the production host set:

tag:application=production

The tag's value must equal production exactly to be included in this host set.

Update the application tag to production by fixing the misconfigured tags in the hosts.tf configuration file.

# Configure the AWS hosts
variable "instances" {
  default = [
    "boundary-1-dev", 
    "boundary-2-dev", 
    "boundary-3-production", 
    "boundary-4-production"
  ]
}

variable "vm_tags" {
  default = [
    {"Name":"boundary-1-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-2-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-3-production","service-type":"database", "application":"production"},
    {"Name":"boundary-4-production","service-type":"database", "application":"prod"}
  ]
}

...
...
...

Lines 13 - 16 define the tags for each VM. Update the application tags on line 16 to match line 15, such that "application":"production".

variable "vm_tags" {
  default = [
    {"Name":"boundary-1-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-2-dev","service-type":"database", "application":"dev"},
    {"Name":"boundary-3-production","service-type":"database", "application":"production"},
    {"Name":"boundary-4-production","service-type":"database", "application":"production"}
  ]
}

Run terraform apply and confirm the new configuration with yes when prompted.

$ terraform apply
aws_security_group.boundary-ssh: Refreshing state... [id=sg-06aa32c32ea2dc6ba]
aws_iam_user.boundary: Refreshing state... [id=boundary]
aws_iam_user_policy.BoundaryDescribeInstances: Refreshing state... [id=boundary:BoundaryDescribeInstances]
aws_iam_access_key.boundary: Refreshing state... [id=AKIASWVU2XLZOLN2IRD3]
aws_instance.boundary-instance[3]: Refreshing state... [id=i-0636d8f305a675a0f]
aws_instance.boundary-instance[0]: Refreshing state... [id=i-0a101da665471ef6c]
aws_instance.boundary-instance[1]: Refreshing state... [id=i-03174fc1e7685ed89]
aws_instance.boundary-instance[2]: Refreshing state... [id=i-09c28775132890622]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_instance.boundary-instance[3] will be updated in-place
  ~ resource "aws_instance" "boundary-instance" {
        id                                   = "i-0636d8f305a675a0f"
      ~ tags                                 = {
          ~ "application"  = "prod" -> "production"
            # (2 unchanged elements hidden)
        }
      ~ tags_all                             = {
          ~ "application"  = "prod" -> "production"
            # (2 unchanged elements hidden)
        }
        # (27 unchanged attributes hidden)





        # (5 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_instance.boundary-instance[3]: Modifying... [id=i-0636d8f305a675a0f]
aws_instance.boundary-instance[3]: Modifications complete after 2s [id=i-0636d8f305a675a0f]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Outputs:

boundary_access_key_id = "AKIASWVU2XLZOLN2IRD3"
boundary_secret_access_key = <sensitive>

The output will display the updated tags, but you can execute aws ec2 describe-instances to directly query for the tag values.

$ aws ec2 describe-instances \
  --instance-ids i-08c588f2d58120192 \
  --output table \
  --query 'Reservations[*].Instances[*].Tags[?contains(Key, `aws`) == `false`]'

-------------------------------------------
|            DescribeInstances            |
+---------------+-------------------------+
|      Key      |          Value          |
+---------------+-------------------------+
|  application  |  production             |
|  service-type |  database               |
|  Name         |  boundary-4-production  |
+---------------+-------------------------+

Perform a read on the missing host.

$ boundary hosts read -id hplg_7KjFRrcLxD

Host information:
  Created Time:        Tue, 18 Jul 2023 10:46:52 MDT
  External ID:         i-0cb29c70786bf3916
  Host Catalog ID:     hcplg_Ia7R4E39oF
  ID:                  hplg_7KjFRrcLxD
  Type:                plugin
  Updated Time:        Tue, 18 Jul 2023 10:46:52 MDT
  Version:             1

  Scope:
    ID:                p_1234567890
    Name:              Generated project scope
    Parent Scope ID:   o_1234567890
    Type:              project

  Plugin:
    ID:                pl_1PRTDb78iY
    Name:              aws

  Authorized Actions:
    no-op
    read

  Host Set IDs:
    hsplg_qnQM03I6yT

  IP Addresses:
    172.31.71.39
    3.239.215.108

  DNS Names:
    ec2-3-239-215-108.compute-1.amazonaws.com
    ip-172-31-71-39.ec2.internal

The External ID: field shows the ID of the misconfigured host (i-0cb29c70786bf3916 in this example). Copy this value.

Recall that host set membership is defined based on the instance tags.

Open the AWS EC2 Console and navigate to the Instances dashboard.

Select the instance whose Instance ID matches the misconfigured host. Then, open it's Tags tab and check the defined values.

Notice that the application tag is misconfigured as prod, instead of production. An easy mistake to make!

Remember the filter defined for the production host set:

tag:application=production

The tag's value must equal production exactly to be included in this host set.

Click Manage tags and update the application tag to production for the misconfigured instance. Click Save when finished.

1. Delete the CloudFormation boundary-dynamic-hosts stack

   $ aws cloudformation delete-stack --stack-name boundary-dynamic-hosts
   

   Wait a minute, then check that the StackStatus has changed to DELETE_COMPLETE.

   $ aws cloudformation list-stacks
   {
     "StackSummaries": [
         {
             "StackId": "arn:aws:cloudformation:us-east-1:157470686136:stack/boundary-dynamic-hosts/05ea64a0-7bbf-11ec-9531-120baac28e1f",
             "StackName": "boundary-dynamic-hosts",
             "TemplateDescription": "AWS CloudFormation template for Boundary Dynamic Hosts tutorial. Deploying this template will incur costs to your AWS account.",
             "CreationTime": "2022-01-22T20:08:11.060000+00:00",
             "DeletionTime": "2022-01-22T21:22:37.577000+00:00",
             "StackStatus": "DELETE_COMPLETE",
             "DriftInformation": {
                 "StackDriftStatus": "NOT_CHECKED"
             }
         }
     ]
   }
   

2. Delete the boundary-keypair EC2 keypair.

   $ aws ec2 delete-key-pair --key-name boundary-keypair
   

3. Delete the boundary user access key.

   Before deleting the boundary user all items attached to the user must be deleted. For more on deleting an IAM user, check the User Guide docs.

   First list the boundary user access keys.

   $ aws iam list-access-keys --user-name boundary
   {
     "AccessKeyMetadata": [
         {
             "UserName": "boundary",
             "AccessKeyId": "AKIASWVU2XLZLFLIDMVW",
             "Status": "Active",
             "CreateDate": "2022-01-19T02:26:11+00:00"
         }
     ]
   }
   

   Copy the AccessKeyId value (AKIASWVU2XLZLFLIDMVW in this example).

   Now delete the access key.

   $ aws iam delete-access-key --user-name boundary --access-key-id AKIASWVU2XLZLFLIDMVW
   

4. Delete the BoundaryDescribeInstances policy.

   $ aws iam delete-user-policy --user-name boundary --policy-name BoundaryDescribeInstances
   

5. Delete the boundary IAM user.

   $ aws iam delete-user --user-name boundary
   

6. Stop Boundary

   HCPDev Mode

   Log in to the HCP portal and delete the HCP Boundary instance.

   Locate the shell where boundary dev was run and enter ctrl+c to stop dev mode.

   ^C==> Boundary dev environment shutdown triggered, interrupt again to force
   ...
   ...
   ...
   {
     "id": "lOp2Pa9JKe",
     "source": "https://hashicorp.com/boundary/dev-controller/boundary-dev",
     "specversion": "1.0",
     "type": "system",
     "data": {
       "version": "v0.1",
       "op": "github.com/hashicorp/cap/oidc.(*TestProvider).startCachedCodesCleanupTicking.func1",
       "data": {
         "msg": "cleanup of cached codes shutting down"
       }
     },
     "datacontentype": "text/plain",
     "time": "2021-08-16T17:06:36.275678-06:00"
   }
   

1. Destroy the Terraform resources in AWS.

   Remove all resources using terraform apply -destroy. Enter yes when prompted to confirm the operation.

   Note

   Terraform 0.15.2+ uses terraform apply -destroy to cleanup resources. If using an earlier version of Terraform, you may need to execute terraform destroy.

   $ terraform apply -destroy
   aws_security_group.boundary-ssh: Refreshing state... [id=sg-06aa32c32ea2dc6ba]
   aws_iam_user.boundary: Refreshing state... [id=boundary]
   aws_iam_user_policy.BoundaryDescribeInstances: Refreshing state...    [id=boundary:BoundaryDescribeInstances]
   aws_iam_access_key.boundary: Refreshing state... [id=AKIASWVU2XLZOLN2IRD3]
   aws_instance.boundary-instance[3]: Refreshing state... [id=i-0636d8f305a675a0f]
   aws_instance.boundary-instance[0]: Refreshing state... [id=i-0a101da665471ef6c]
   aws_instance.boundary-instance[2]: Refreshing state... [id=i-09c28775132890622]
   aws_instance.boundary-instance[1]: Refreshing state... [id=i-03174fc1e7685ed89]
   
   Terraform used the selected providers to generate the following execution plan. Resource actions are    indicated with the following symbols:
     - destroy
   
   Terraform will perform the following actions:
   
     # aws_iam_access_key.boundary will be destroyed
     - resource "aws_iam_access_key" "boundary" {
         - create_date          = "2022-01-28T18:44:18Z" -> null
         - id                   = "AKIASWVU2XLZOLN2IRD3" -> null
         - secret               = (sensitive value)
         - ses_smtp_password_v4 = (sensitive value)
         - status               = "Active" -> null
         - user                 = "boundary" -> null
       }
   
     # aws_iam_user.boundary will be destroyed
     - resource "aws_iam_user" "boundary" {
         - arn           = "arn:aws:iam::186136574706:user/boundary" -> null
         - force_destroy = false -> null
         - id            = "boundary" -> null
         - name          = "boundary" -> null
         - path          = "/" -> null
         - tags          = {} -> null
         - tags_all      = {} -> null
         - unique_id     = "AIDASWVU2XLZPCRFR4LW7" -> null
       }
   
     # aws_iam_user_policy.BoundaryDescribeInstances will be destroyed
     - resource "aws_iam_user_policy" "BoundaryDescribeInstances" {
         - id     = "boundary:BoundaryDescribeInstances" -> null
         - name   = "BoundaryDescribeInstances" -> null
         - policy = jsonencode(
               {
                 - Statement = [
                     - {
                         - Action   = [
                             - "ec2:DescribeInstances",
                           ]
                         - Effect   = "Allow"
                         - Resource = "*"
                       },
                   ]
                 - Version   = "2012-10-17"
               }
           ) -> null
         - user   = "boundary" -> null
       }
   
     # aws_instance.boundary-instance[0] will be destroyed
     
   ...
   ... Tuncated Output ...
   ...
   
   Plan: 0 to add, 0 to change, 8 to destroy.
   
   Changes to Outputs:
     - boundary_access_key_id     = "AKIASWVU2XLZOLN2IRD3" -> null
     - boundary_secret_access_key = (sensitive value)
   
   Do you really want to destroy all resources?
     Terraform will destroy all your managed infrastructure, as shown above.
     There is no undo. Only 'yes' will be accepted to confirm.
   
     Enter a value: yes
   
   aws_iam_user_policy.BoundaryDescribeInstances: Destroying... [id=boundary:BoundaryDescribeInstances]
   aws_iam_access_key.boundary: Destroying... [id=AKIASWVU2XLZOLN2IRD3]
   aws_instance.boundary-instance[2]: Destroying... [id=i-09c28775132890622]
   aws_instance.boundary-instance[1]: Destroying... [id=i-03174fc1e7685ed89]
   aws_instance.boundary-instance[0]: Destroying... [id=i-0a101da665471ef6c]
   aws_instance.boundary-instance[3]: Destroying... [id=i-0636d8f305a675a0f]
   aws_iam_access_key.boundary: Destruction complete after 0s
   aws_iam_user_policy.BoundaryDescribeInstances: Destruction complete after 0s
   aws_iam_user.boundary: Destroying... [id=boundary]
   aws_iam_user.boundary: Destruction complete after 0s
   aws_instance.boundary-instance[0]: Still destroying... [id=i-0a101da665471ef6c, 10s elapsed]
   aws_instance.boundary-instance[2]: Still destroying... [id=i-09c28775132890622, 10s elapsed]
   aws_instance.boundary-instance[1]: Still destroying... [id=i-03174fc1e7685ed89, 10s elapsed]
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 10s elapsed]
   aws_instance.boundary-instance[0]: Still destroying... [id=i-0a101da665471ef6c, 20s elapsed]
   aws_instance.boundary-instance[1]: Still destroying... [id=i-03174fc1e7685ed89, 20s elapsed]
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 20s elapsed]
   aws_instance.boundary-instance[2]: Still destroying... [id=i-09c28775132890622, 20s elapsed]
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 30s elapsed]
   aws_instance.boundary-instance[0]: Still destroying... [id=i-0a101da665471ef6c, 30s elapsed]
   aws_instance.boundary-instance[2]: Still destroying... [id=i-09c28775132890622, 30s elapsed]
   aws_instance.boundary-instance[1]: Still destroying... [id=i-03174fc1e7685ed89, 30s elapsed]
   aws_instance.boundary-instance[0]: Destruction complete after 31s
   aws_instance.boundary-instance[1]: Destruction complete after 31s
   aws_instance.boundary-instance[2]: Destruction complete after 31s
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 40s elapsed]
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 50s elapsed]
   aws_instance.boundary-instance[3]: Still destroying... [id=i-0636d8f305a675a0f, 1m0s elapsed]
   aws_instance.boundary-instance[3]: Destruction complete after 1m2s
   aws_security_group.boundary-ssh: Destroying... [id=sg-06aa32c32ea2dc6ba]
   aws_security_group.boundary-ssh: Destruction complete after 2s
   
   Apply complete! Resources: 0 added, 0 changed, 8 destroyed.
   
   

2. Remove the terraform state files.

   $ rm *.tfstate*
   

3. Stop Boundary

   HCPDev Mode

   Log in to the HCP portal and delete the HCP Boundary instance.

   Locate the shell where boundary dev was run and enter ctrl+c to stop dev mode.

   ^C==> Boundary dev environment shutdown triggered, interrupt again to force
   ...
   ...
   ...
   {
     "id": "lOp2Pa9JKe",
     "source": "https://hashicorp.com/boundary/dev-controller/boundary-dev",
     "specversion": "1.0",
     "type": "system",
     "data": {
       "version": "v0.1",
       "op": "github.com/hashicorp/cap/oidc.(*TestProvider).startCachedCodesCleanupTicking.func1",
       "data": {
         "msg": "cleanup of cached codes shutting down"
       }
     },
     "datacontentype": "text/plain",
     "time": "2021-08-16T17:06:36.275678-06:00"
   }
   

1. Delete the CloudFormation boundary-dynamic-hosts stack

   Navigate to the CloudFormation Dashboard. Select the boundary-dynamic-hosts Stack name. Then click Delete and confirm by clicking Delete stack.

   When the delete is complete, the stack's Status will change to DELETE_COMPLETE.

   

2. Delete the boundary-keypair EC2 keypair.

   Navigate to the EC2 Console Dashboard. Select Key Pairs under Network & Security on the left side of the page.

   Check the box next to boundary-keypair, then select the Actions dropdown and click Delete. Confirm the deletion of the keypair by typing "Delete" in the field and clicking Delete again.

   

3. Delete the boundary user and associated access key.

   Navigate to the IAM Dashboard. Select the Users panel, then check the box next to the boundary user. Click Delete, and confirm by typing the name of the user boundary and clicking Delete again. This will also delete the access key associated with the user.

   

4. Delete the BoundaryDescribeInstances policy.

   Click on the Policies panel, and select the BoundaryDescribeInstances policy. Then click the Actions dropdown and select Delete.

   Confirm by typing the name of the policy BoundaryDescribeInstances into the field and clicking Delete.

   

5. Stop Boundary

   HCPDev Mode

   Log in to the HCP portal and delete the HCP Boundary instance.

   Locate the shell where boundary dev was run and enter ctrl+c to stop dev mode.

   ^C==> Boundary dev environment shutdown triggered, interrupt again to force
   ...
   ...
   ...
   {
     "id": "lOp2Pa9JKe",
     "source": "https://hashicorp.com/boundary/dev-controller/boundary-dev",
     "specversion": "1.0",
     "type": "system",
     "data": {
       "version": "v0.1",
       "op": "github.com/hashicorp/cap/oidc.(*TestProvider).startCachedCodesCleanupTicking.func1",
       "data": {
         "msg": "cleanup of cached codes shutting down"
       }
     },
     "datacontentype": "text/plain",
     "time": "2021-08-16T17:06:36.275678-06:00"
   }