Using KMS Between Commercial and GovCloud

I have multiple targets I want to reach in govcloud and commercial accounts.
However, I can’t share KMS resources between govcloud and commercial accounts, or AssumeRole from one account to another.

So that leaves the question, how do Worker nodes access the worker-auth key over multiple partitions?

What’s the best way of going about this?
Should I use AEAD? Should I use Vault? Is there a way to simply use two KMS keys, one for commercial, one for govcloud?

Tried this demo looking for answers, but the guy literally hardcodes an AEAD key and just avoids KMS altogether :pensive:

Using HashiCorp Boundary for Identity-Based Multi-Cloud Access

The simplest thing is to just have two Boundary installations, and have users switch between them. The desktop client allows this with the “Change origin URL” link on the login screen. Not as simple to administer as you’re looking for (though I think the Terraform provider can alleviate some of the tedium), but in most of the .gov environments I’ve worked in, this is what I would have been required to do anyway.

As far as spreading Boundary workers between GovCloud and regular AWS, Boundary doesn’t care if you use a different supported KMS than the environment you’re in, as long as everything can access the keys they need. But for worker auth, all the controllers and all the workers need to be able to access the worker-auth key, and all the controllers need access to the same root and recovery keys as each other, so I don’t know if you’ll be able to run a commercial+GovCloud unified environment in a way that’s compliant with the policy restrictions you’re under.

Wouldn’t the Vault Auto-Auth be pefect for this kind of thing? Set up a vault agent to constantly generate tokens (and verify said agent by using a specific AWS role ARN) and then consume them in the transit engine instead of using a KMS.

Vault is definitely a better choice than static AEAD keys in pretty much all ways. I just don’t know if having Boundary workers in both environments as part of a single Boundary installation is going to be OK with your security folks given the intent of GovCloud – you’ll either have workers in commercial AWS reaching into GovCloud, or GovCloud workers reaching into commercial AWS. (Then again, maybe you are your security folks, in which case, you get to decide :grin: )

The best option if you have a Vault Enterprise deployment is going to be one cluster in GovCloud and one in commercial AWS performance-replicating those Transit keys to each other, as long as that kind of replication is OK policy-wise on your end. (It’s probably going to be easier to justify than direct client access across the GovCloud perimeter, at any rate.)

And either way, you’ll still have to figure out what Boundary client access to the Boundary controllers and workers looks like.

You know your security policy better than I do, I just don’t want to steer you in a direction that’s going to get you in hot water with a COTR or something :slight_smile:

1 Like

If you’re using Vault and Vault is accessible from all parties you can use its Transit engine as a KMS.

I may not be following the exact requirement, but is the issue purely that all workers need access to the same KMS, or controllers too? We could potentially add multiple worker auth key support, but in the end the controllers still need access to all of them.

Currently to my understanding Boundary only supports one single Worker-Auth key. This is shared between the controllers and all workers, right? (Please correct me if I’m wrong)

The problem is that once you have more than one cloud provider in the boundary deployment, verifying the KMS key across both all workers and controllers is impossible (i.e. I can’t apply AWS IAM to verify access to an Azure KMS key or vice versa) unless using vault. As you said, the controllers still need access to all of the KMS keys.

I don’t exactly know how or if this problem can be solved at all. Maybe if you had multiple clusters of controllers in multiple clouds working/partitions together (but that brings up a whole lot of issues, namely how do you make sure THOSE work together as well?) (and at that point, it’s probably easier to just have multiple addresses registered in your boundary client).