hashicorp/vault-guides

Vault AWS Quick-start deployment using SAML/AssumeRole

cvbarros opened this issue · 5 comments

Hello!

We're evaluating vault and started trying one of the quick star deployments, but we're currently unable to run a clean terraform apply because it doesn't respect the configuration on main.tf' regarding the aws provider required for assume_role`.

Hence, we get an error stating:

Error: Error refreshing state: 2 error(s) occurred:

* module.network_aws.data.aws_availability_zones.main: 1 error(s) occurred:

* module.network_aws.data.aws_availability_zones.main: data.aws_availability_zones.main: Error fetching Availability Zones: UnauthorizedOperation: You are not authorized to perform this operation.
        status code: 403, request id: ----------cleared-----------------
* data.aws_ami.base: 1 error(s) occurred:

* data.aws_ami.base: data.aws_ami.base: UnauthorizedOperation: You are not authorized to perform this operation.
        status code: 403, request id: ----------cleared-----------------

However, if we create a blank main.tf file and configure this as:

provider "aws" {
  region = "eu-west-1"

  assume_role {
    role_arn     = "arn:aws:iam::--------cleared-----------"
  }
}

data "aws_availability_zones" "main" {}

And then run a terraform apply, we're able to make it and properly see an output for the AZs:

data.aws_availability_zones.main: Refreshing state...

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

Outputs:

availability_zones = [
    eu-west-1a,
    eu-west-1b,
    eu-west-1c
]

As a side-effect, also the provider settings such as region and profile are also not respected (maybe related to this issue?), which then we have to resort to env variables such as AWS_REGION to make it work.

@cvbarros - apologies for the delay, wasn't receiving notifications on this repo!

I'm not sure if there's a way to set the assume_role block within the aws provider via environment variables, which would be my preferred way of handling this as not everyone will use that method for authentication. I think that by explicitly defining the assume_role block in main.tf, if someone does not provide the role_arn it will throw an error, which wouldn't be a great first experience.

Are you able to set this in a shared_credentials_file? See #52 (comment) for how to define those env vars. Let me know if that will work, otherwise I can look into other ways to handle.

Hello @bensojona , I've managed to get the code above working by clearing individual provider blocks from inside the modules (in my local folder after running terraform init).

It is indeed related to this comment, so this issue should be more suitable for each's modules, for instance: https://github.com/hashicorp-modules/network-aws/blob/f7af7faa498d563cff6b3790f2da9b99d472bf66/main.tf#L5

Whereas it is stated as best practice to declare provider blocks only on the top-level module, per the comment above. I'll close this issue since I managed to get a workaround, thanks! 👍

@cvbarros interesting - I'll take a look at updating, thanks!

@cvbarros I had been looking at the Using Modules section that mentioned you should version each provider.

We recommend explicitly constraining the acceptable version numbers for each external module to avoid unexpected or unwanted changes.

Seems like that conflicts with the Providers within Modules.

That said, I think putting only defining the provider in the root module makes the most sense, especially as I often have issues removing modules without first destroying for that same reason.

@cvbarros - okay, updated. If you want to give it a shot by doing a terraform get -update it should work as expected. Let me know!