Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

s3 backend role chaining permission failure #36507

Open
Folling opened this issue Feb 13, 2025 · 3 comments
Open

s3 backend role chaining permission failure #36507

Folling opened this issue Feb 13, 2025 · 3 comments
Labels
backend/s3 bug new new issue not yet triaged

Comments

@Folling
Copy link

Folling commented Feb 13, 2025

Terraform Version

Terraform v1.10.5
on darwin_arm64

Terraform Configuration Files

This works:

backend "s3" {
  bucket  = "redacted"
  region  = "redacted"
  key     = "redacted.tfstate"
  encrypt = true

  assume_role = {
    role_arn = "arn:aws:iam::1234567890:role/redacted"
  }
}

This fails:

backend "s3" {
  bucket  = "redacted"
  region  = "redacted"
  key     = "redacted.tfstate"
  encrypt = true

  assume_role = {
    role_arn = "arn:aws:iam::0987654321:role/redacted"
  }

  assume_role = {
    role_arn = "arn:aws:iam::1234567890:role/redacted"
  }
}

Debug Output

The first example initialises fine, the second fails with:

│ Error: Error loading state:
│     Unable to access object "redacted.tfstate" in S3 bucket "redacted": operation error S3: HeadObject, https response error StatusCode: 403, RequestID: redacted, HostID: redacted, api error Forbidden: Forbidden
│
│ Terraform failed to load the default state from the "s3" backend.
│ State migration cannot occur unless the state can be loaded. Backend
│ modification and state migration has been aborted. The state in both the
│ source and the destination remain unmodified. Please resolve the
│ above error and try again.

Expected Behavior

The request should work with chained role assumptions.

Actual Behavior

It fails with a role inbetween.

Steps to Reproduce

  1. terraform init

Additional Context

I have manually verified that

  1. The role has access (by assuming it directly)
  2. The chain is intact (assuming works on the CLI and the final role has access to S3 if role-chained)

I am also suspect that the roles are actually chained. The following configuration:

backend "s3" {
  bucket  = "redacted"
  region  = "redacted"
  key     = "redacted.tfstate"
  encrypt = true

  assume_role = {
    role_arn = "arn:aws:iam::0987654321:role/redacted"
  }

  assume_role = {
    role_arn = "gibberish_arn"
  }
}

Still yields the "403" error, instead of a "invalid ARN" error, as I would have expected.

The documentation is a bit iffy as well. It just says "multiple values can be specified", but isn't clear about whether that means

  1. passing an array of objects
  2. passing multiple role_arn properties in the object
  3. passing multiple blocks, like in the provider config.

I tried all of these and more, but looking at the source code I believe my above code is what would be intended.

References

Generative AI / LLM assisted development?

No response

@Folling Folling added bug new new issue not yet triaged labels Feb 13, 2025
@jbardin
Copy link
Member

jbardin commented Feb 14, 2025

Hi @Folling,

This looks like an error in the configuration, you can't assign different things to the same attribute and the above configuration returns an Attribute redefined error during decoding so you shouldn't be able to get past initialization. Can you show how you are getting to the point of receiving a response from AWS with the given configuration?

@Folling
Copy link
Author

Folling commented Feb 14, 2025

The attribute explicitly is supposed to allow for multiple values to allow for AWS role chaining.

This is supposed to provide parity with the AWS provider, which supports this feature here.

#36454 also talks about this feature, where they were able to get it running somehow. Which is confusing to me because:
The feature was implemented in #35720 but was reverted in #35827.

Looking at

var assumeRoleSchema = singleNestedAttribute{
it doesn't seem like it was ever re-renabled again.

But that conflicts with the documentation here and with the discussion in #36454.

@jbardin
Copy link
Member

jbardin commented Feb 14, 2025

Yeah, I also don't understand what was going on in #36454, but you're correct about the configuration, the schema is explicitly a single attribute. I suspect it's a discrepancy in the documentation, but I'll wait for the AWS developers to chime in on the actual intent here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend/s3 bug new new issue not yet triaged
Projects
None yet
Development

No branches or pull requests

2 participants