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

Expose data sources that allow for looking up existing IAM policies #14095

Closed
geojaz opened this issue Mar 26, 2023 · 3 comments
Closed

Expose data sources that allow for looking up existing IAM policies #14095

geojaz opened this issue Mar 26, 2023 · 3 comments

Comments

@geojaz
Copy link
Contributor

geojaz commented Mar 26, 2023

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

For essentially all resources in this provider, there's a datasource that does a "lookup"/get of the current state- except for IAM. In IAM, the datasource is used to DEFINE policy rather than GET the policy. Why?

This feels like a "strange" gap in our support given there are gcloud commands like gcloud projects get-iam-policy --project=$PROJECT_ID or gcloud iam service-accounts get-iam-policy $GSA_ID that return useful information.

There must be some history here for why IAM policies can't be a resource with a corresponding datasource, but I'm not aware of it. Is there a way we could support IAM policy lookups like this without breaking existing usage?
For context, I would like to be able to do this in terraform, it's bitten me a couple times, but this actually comes from a user that is consume the terraform provider via pulumi.

I'm not sure what the best path forward is, but wanted to get this issue created for discussion.

New or Affected Resource(s)

We should keep the scope limited, perhaps we try 2 new datasources and see how those go?

  • data "google_project_iam_policy" (roughly equivalent to gcloud projects get-iam-policy --project=$PROJECT_ID)
  • data "google_service_account_iam_policy" (roughly equivalent to gcloud iam service-accounts get-iam-policy $GSA_ID)

Potential Terraform Configuration

data "google_project_iam_policy" "project" {
  project = "project-id"
}
output "project-id-iam-policy" {
  value = data.google_project_iam_policy.project
}

data "google_service_account_iam_policy" "gsa1" {
  account_id = "my-gsa"
}
output "my-gsa-policy" {
  value = data.google_service_account_iam_policy.gsa1
}

b/273370142

@rileykarson
Copy link
Collaborator

In IAM, the datasource is used to DEFINE policy rather than GET the policy. Why?

data.google_iam_policy provides an HCL interface to produce policy JSON which can be fed in to policy_data. I think that it was implemented that way for historical reason- project IAM support was initially a part of the google_project resource where a policy_data field of raw JSON made sense. It's implemented as a datasource because output values of datasources are computed before plan where possible (i.e. unless there's a resource the datasource is dependent on) and output values on resources would be available post-apply, so policy changes would not be reflected in plan.

Looking at this, it would make a lot of sense to support HCL policies directly on the policy resource instead (but really support both in parallel- the impact would be large enough that we should never deprecate policy_data).


I'm not sure what the utility of these lookups would be for Terraform users- they'd be difficult to string through a configuration- but this wouldn't be hard enough to implement or confusing enough to users to block on that, really. Other tools with Terraform [provider]-based providers/operators could derive more utility from datasource support, though.

For context, I would like to be able to do this in terraform, it's bitten me a couple times

@geojaz what would support have unblocked for you specifically? I'm wondering about that to apply to datasources-in-general, most of the time today when evaluating their utility I'm looking for "could a user use this in configuration?".

@rileykarson
Copy link
Collaborator

We should keep the scope limited, perhaps we try 2 new datasources and see how those go?

  • data "google_project_iam_policy" (roughly equivalent to gcloud projects get-iam-policy --project=$PROJECT_ID)
  • data "google_service_account_iam_policy" (roughly equivalent to gcloud iam service-accounts get-iam-policy $GSA_ID)

It'll probably be the same amount of work to do this for 1-2 than to just do it for them all, honestly. @ScottSuarez this issue will cover adding a datasource output to our IAM framework that applies to all IAM types.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants