Terraform: Feature Request: What IAM permissions do I need to apply?

Created on 27 Sep 2017  ยท  4Comments  ยท  Source: hashicorp/terraform

I'm not sure if this is the right place for a high-level feature request like this, but here it goes:

Give the ability to, with an option like terraform apply -dry-run, list the permissions and potential API calls required to do the terraform apply when you actually run it.

I cannot tell you how many times I've gone to do a plan and everything works, but then on an apply, only a few things work because I don't have the right IAM permissions. This encourages teams who use terraform to have a blanket * policy or at least one that is far too permissive. With this option, not only would teams be able to see exactly what changes they are trying to make, but it would help out teams that manage security for IAM better understand what the least privilege for common terraform activities. This way, we can have potentially less privilege without causing friction to infrastructure teams.

I'm not even sure if this is even possible, but I figure if anyone can do it, it's the fine gentlefolk of Hashicorp.

enhancement provideaws

Most helpful comment

This would make a great feature. Given the complexities in predicting the IAM permissions used, as eloquently argued by @apparentlymart, would it be possible for Terraform to report the permissions that were used _after_ an apply? As opposed to from a plan or a dry-run?

All 4 comments

Hi @onetwopunch!

This is indeed a problem we've seen before, and a tricky one to solve, for a few reasons:

  • It's not always clear which permissions are required for a given action. While in many cases there's a one-to-one relationship between API endpoints and actions, there are often "hidden" requirements, such as iam:PassRole for allowing services to access one another, and these are generally not documented in either a machine-readable way or a _systematic_ human-readable way.
  • The actions used by a resource can change over time as we add support for new features. Many AWS provider resources actually need to use multiple API calls behind the scenes to do their work, especially for older APIs where new features have been introduced via new actions over time, and each one of these will usually have its own action. Since Terraform needs to _read_ everything in order to detect drift, it's not generally reasonable to provide an opt-in for such new features, although we do try where possible.
  • IAM is a pretty complex system in any case, with multiple ways to achieve the same results, and so different organizations will often use it in different ways depending on their organizational structure, regulations, etc.

We are always on the lookout for ways to do better here, but for now the only way to achieve the goal of minimal permissions is to fix to a specific Terraform version, use the AWS documentation for the services in question to find the _documented_ policies needed, and then use trial and error :confounded: to find out all the "hidden" requirements. This process needs to then be repeated for each upgrade, though at least in that case the provider changelog can help you narrow down the work.

A middle-ground solution adopted by some organizations without such tight requirements is to constrain Terraform to specific services in specific regions (e.g. using ec2:*-style action specifications, and ARN wildcards for regions) and then in turn control access to _Terraform itself_ by running it in some sort of automation system that keeps these privileged credentials centralized in one place that can be secured well. This sort of approach is not without its risks, of course, but each organization must make its own tradeoffs between security and other concerns depending on its context.

We'd previously had an issue open about this in the AWS provider but eventually closed it because we were not able to find a suitable way to proceed. (Unfortunately I couldn't find the issue I'm referring to since it's quite an old one.) Sadly we have no new information here, so I'm going to close this one not because it isn't a good idea -- we'd love to be able to do something like this -- but because it seems like a rather insurmountable problem in the general case.

Thanks again for suggesting it. We'll keep an eye out for ways to do better here in future.

This would make a great feature. Given the complexities in predicting the IAM permissions used, as eloquently argued by @apparentlymart, would it be possible for Terraform to report the permissions that were used _after_ an apply? As opposed to from a plan or a dry-run?

Maybe do a run with a high-powered user and afterwards see what what used using CloudTracker? https://github.com/duo-labs/cloudtracker

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

oillio picture oillio  ยท  78Comments

amaczuga picture amaczuga  ยท  124Comments

kklipsch picture kklipsch  ยท  95Comments

radeksimko picture radeksimko  ยท  80Comments

bloopletech picture bloopletech  ยท  82Comments