Boundary Onboarding

Boundary
1

I’m having trouble figuring out the best approach to onboarding targets in HashiCorp Boundary.

We have two requirements: first,

  1. we have no user mapping at the IDP level, and second,
  2. we don’t want to use the AWS dynamic host catalogue.

We have 400 servers in AWS, each with three different credentials (root, read, and viewer access). Initially, we used a static host set to group instances wherever possible. However, we now need to have each target in triplicate for each credential type, and then specify as many targets as required by the user in the grants. We then assigned user access to the target by specifying the target ID in the grants of a role. We’re exploring the possibility of using a 1-to-1 mapping between target IP addresses and credentials in target, target IDs and grants, and principles at project, orgs and global scope.

2

Given requirement #2 especially, some thoughts:

First, you are correct in your analysis - the target is what pulls things together - the networked endpoint, any credentials associated with the session, controls around the session itself. You can have multiple hosts described by one target via a host set, but you can’t have multiple mappings of hosts ↔ credentials - those are separate targets.

A couple of things to think about though that, while they may not reduce target count, may help with figuring out how you want to deploy things:

  • You can specify multiple IDs in a grant, so you can cover many targets at once by a single role if you want the same set of principals to access them
  • As of Boundary 0.15 roles can apply to more than one (downstream) scope. So you can use orgs and/or projects to make it easier to separate out access without having a ballooning of the number of roles. E.g. you can create a role that gives a particular group access to sessions from targets across X, Y, and Z projects, or all child projects.
  • In 0.16 there will be aliasing support, which will allow you to define a friendly global alias to targets, which can include a selector of which host from a host set is used from that target when invoked via the alias. This can potentially allow you to make better use of host sets and have a larger number of aliases instead of targets, if you need access to specific hosts in a target’s host set.