Creating "OAuth 2.0 Client IDs" (from GCP console) using this provider

[MPV]

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

I'd like to be able to use Terraform to create the OAuth 2.0 Client IDs showing up here:
https://console.cloud.google.com/apis/credentials

Ideally both Type: Other and Type: Web application.

I have found this resource, but I'm not sure if this is the same as the Type: Other?
https://www.terraform.io/docs/providers/google/r/identity_platform_oauth_idp_config.html

I couldn't find any equivalent TF resource for Type: Web application?

New or Affected Resource(s)

• Couldn't find any?
• Possibly identity_platform_oauth_idp_config?

Potential Terraform Configuration

# I would use TF to create my OAuth OIDC apps in GCP as code...
# ...and then configure my Kubernetes/OpenShift clusters to use these client IDs and secrets

References

OIDC:
https://developers.google.com/identity/protocols/oauth2/openid-connect

OAuth2 for web applications:
https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow#creatingcred

We also discussed this briefly in #1287 (comment).

[danawillow]

Labeling documentation since we think this is already doable, but we could be more explicit with how.

[boostrack]

How #1287 ? @danawillow I am also looking for https://console.cloud.google.com/apis/credentials

[wilhelmi]

Would like to be able to create credentials of type IOS rather than the Web Application type that gets created from the resources referenced in #1287

[Backstreets]

Just to add: we would like to be able to create OAUTH2 Client Ids (Web applications), as mentioned by MPV, for the Oauth screen (brand) that's already created via Console in a GCP Project.
Thanks!

[Chupaka]

@Backstreets

for the Oauth screen (brand) that's already created via Console in a GCP Project.

Can't you just import oauth screen to Terraform?

[Backstreets]

@Chupaka, what I meant is that we (in our case) dont need to create the Oauth screen from terraform, as it is already created in GCP. What we need is the ability to create OAuth2 clients (web applications) with Terraform, that can be related to that Oauth screen.
Thanks!

[imortkz]

Just want to add that it would be very helpful to have that for me too.

Ideally, it should allow create OAuth 2.0 client with type web application, providing both allowed JS URI's and redirect URI's lists.
I has to do it manually at this moment.

[slevenick]

@Backstreets and @imortkz can you elaborate on what you would like to be able to accomplish via Terraform? Specifically if there are APIs that provide the functionality but we haven't implemented it in Terraform. Generally you can find this by finding a series of gcloud commands that accomplish the task

I think some of the issue here is that the APIs don't exist, which means we can't support the use case in Terraform. If this is the case it may be helpful to file tickets against the upstream APIs to add this functionality here: https://cloud.google.com/support/docs/issue-trackers

What is currently supported at the moment would be using a manually created iap_brand to create a google_iap_client (https://www.terraform.io/docs/providers/google/r/iap_client.html) that creates the client id and secret to be used within (for example) an App Engine app: https://www.terraform.io/docs/providers/google/r/app_engine_application.html#iap

[slevenick]

Hm, yeah I see the issue. This step is seemingly impossible via terraform or any programmatic tool. I don't see applicable REST resources for the redirect URLs or even the type of client. The existing resources are here but only allow for setting a few fields.

I think at this point the only way to configure these fields is through the console, but I would recommend filing a feature request

[Backstreets]

@slevenick

In my case this is the situation:

Im creating an IAP protected infra with terraform, and for the back ends I use:

resource "google_compute_backend_service" "my-be" {
depends_on = [google_compute_instance_group.r-instance-group]
name = "my-webserver-be"
health_checks = [google_compute_health_check.hc-my.self_link]
load_balancing_scheme = "EXTERNAL"
session_affinity = "CLIENT_IP"
connection_draining_timeout_sec = 300
port_name = join("",["http",var.my-port-string])
backend {
group = google_compute_instance_group.r-instance-group.self_link
}
iap {
oauth2_client_id = var.rserver-oauth2-client-id
oauth2_client_secret = var.rserver-oauth2-secret
}
}

The only way I found to be able to do this is by creating the oauth2 client by hand, including its Authorized redirect URI, and then having the oauth2_client_id email address and secret explicitly written in a var file, so I can use them in the iap block of the compute_back_end resource shown above.

I think there could be two alternatives for this: 1) being able to create the oauth2_client from terraform, including its redirect urls, and reference its id and secret without having to write the secret to a file (and destroy the oauth2_client when using terraform destroy), or 2) be able to reference an oauth2_client_id previously create by hand, and get its secret by reference and use it in iap block.

Does it make sense?

Thanks a lot, regards

[slevenick]

Thanks for the detailed explanation. I believe #2 should be possible. If you create the oauth client by hand, and then use the iap_client resource to import it, you should be able to get the client id and secret.

Unfortunately, option 1 would require new API endpoints, as the existing ones do not allow configuring redirect URLs, so this is not an option currently.

[Backstreets]

Hmm Im guess i'm having a hard time understanding how to relate the "brand" in:

$ terraform import google_iap_client.default {{brand}}/identityAwareProxyClients/{{client_id}}
$ terraform import google_iap_client.default {{brand}}/{{client_id}}

[brand - (Required) Identifier of the brand to which this client is attached to. The format is projects/{project_number}/brands/{brand_id}/identityAwareProxyClients/{client_id}.]

with the OAuth 2.0 Client I created manually in the console to use with IAP.

Can´t find what would be my "brand" or how to identify the client I need to import.

[gmartinez-anchor]

@Backstreets you can get the brand with:

gcloud alpha iap oauth-brands list --project=xxxx

and then you can get the client info with:

gcloud alpha iap oauth-clients list projects/xxxxxxx/brands/xxxxxxxxx

[Backstreets]

@gmartinez-anchor Thanks, will give a try!

[Backstreets]

Just a quick qs: If I import the client that way, and then I do a terraform destroy of my infra, will it destroy the imported client too? I mean, will I have to recreate the client by hand everytime or it will be preserved as it was not created by TF?
Thxs!

[slevenick]

If the client is imported it will then be managed by terraform. You can prevent this by tagging it as prevent destroy but that will cause terraform that attempt to destroy this client to fail. To get around that you could terraform rm the client before destroying which would remove it from state, preventing the actual client from being destroyed.

It may be more useful to you as a datasource though. I would recommend filing an issue for adding a datasource for this resource

[Backstreets]

Thanks a lot @slevenick , will do that.

[MajorBreakfast]

I find myself also in need of this resource. My use case is fully automating our internal GitLab installation including single sign-on via Google. From the instructions at https://docs.gitlab.com/ee/integration/google.html it seems that what's missing is the functionality described by @MPV and more specifically what @imortkz describes in their comment above.

[slevenick]

@MajorBreakfast unfortunately that is not possible in Terraform as APIs to manage many of the fields on iap_client do not exist. These changes must be done manually through the GCP console.

I do not expect APIs for managing these fields to be available in the near future, so I will add notes on the google_iap_client resource that explain that manual steps must be taken to use a client created via Terraform.

[stepan111]

@slevenick and can we have a data source to reference existing resources ? I suppose it may help in cases when you create iap_client manually and then refer to it within terraform. Basically I am searching for secure way to get Client ID and Client Secret.

[MajorBreakfast]

@stepan111 At the project I'm working on, we were able to create a neat automated setup for this use case and I'm quite happy with it. So, maybe this helps: We create the OAuth brand centrally at the location where we create the google cloud project. The brand is a singleton and can only be created once per project. For each use case we create a different IAP client. The lack of a data source is no problem because we don't share the IAP clients. To create the client we derive the brand id from the project number.

I realize that the discussion around a data source is off-topic ^^' Just wanting to help. Additional discussion should probably happen in a different issue, though

[Backstreets]

@stepan111 "and can we have a data source to reference existing resources ?" This is exactly what enhancement request #6482 is about.

[slevenick]

Closing, I added a note on this behavior to the client resource. Fully configuring the client is not possible via the API, and must be done manually.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!