Terraform allows assumption of roles with the AWS provider. However it seems the Boundary provider doesn’t use the AWS provider, nor provide an option for setting the profile to assume to read the key?
The only way I can get this to work is to login and set the AWS_PROFILE environment variable before running Terraform, which defeats CI testing implementations.
Would be great if it supported assuming profiles similar to or making use of Terraform’s AWS provider.
Note: The client uses the official AWS SDK and will use the specified credentials, environment >credentials, shared file credentials, or IAM role/ECS task credentials in that order, if the above AWS specific values are not provided.
If you’re on an EC2 instance, you can leverage the role as an instance profile. Under the hood, we’re running the AWS SDK, and so all env vars and other authentication mechanisms should happen automatically.
When using the Terraform provider you are running from a workstation or CI system, not from the instance node.
Yes, it would be possible to create a CI node in EC2 which has a god-like instance profile, but this is a lot less secure than specific role assumption rights given to specific jobs.
If you are using the AWS provider with role assumption, you can’t use the environment variables for all the reasons this ability was added to the AWS provider. (multiple roles are used for this deployment)
The AWS provider is based on the same SDK, so it would have the same abilities if you added the same attributes to the Boundary provider schema.
I’m still not following the workflow clearly here. In the example, you have a awskms block, that block specifies a KMS key, not IAM configuration, for encrypting different types of Boundary traffic. How are you using Boundary from CI? Can you clarify if this is something you’re doing from Terraform (and the specific provider, it sounds like you’re using Boundary and AWS providers), or Boundary itself?
Yes. In order to read that key, one must assume the correct IAM profile. There’s no way to do that today except by setting environment variables… which breaks all other AWS operations in the same Terraform run.
I’m asking you to add the ability to assume an AWS profile in order to read the KMS provided.
I landed on the originating Github issue trying to work through a similar problem. We use cross-account assume roles heavily in our CD environment, which is something the AWS provider handles well (including using provider aliases to be able to access multiple accounts’ resources from one module).
It looks like the solution is being able to add an AssumeRoleProvider to the credentials chain in that method with the role_arn from the KMS config HCL, but we’ve reached the limit of how much I understand Go (including how to hack on this library to test locally).
If you’re on an EC2 instance, you can leverage the role as an instance profile.
I realize this project is pre-alpha, whatever. And I’m not expecting 24 hour turnaround… but 14 months later this still isn’t possible. You’ve added Saml-based web token role assumption (which is a child class of this) without handling the base scenario.
This remains the blocker for rollout/usage for us, and quite a few others given the comments. I’ve gone far enough to write a PR to fix it. Can we get some attention on this please?
Hi @jorhett! Apologies for the delay. We will be looking at the PR you’ve filed; since it is outside the “scope” of a single product, we’ll be working on this as a cross-team effort. I’ll do my best to shepherd this along. Thanks for your patience and your initial efforts to get this going! It is truly appreciated.