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

allow oauth_scopes = default for google_container_cluster #1817

Closed
naseemkullah opened this issue Jul 26, 2018 · 2 comments
Closed

allow oauth_scopes = default for google_container_cluster #1817

naseemkullah opened this issue Jul 26, 2018 · 2 comments

Comments

@naseemkullah
Copy link

naseemkullah commented Jul 26, 2018

Just like in the UI... thanks!

image

@paddycarver paddycarver added this to the Backlog milestone Dec 13, 2019
slevenick pushed a commit to slevenick/magic-modules that referenced this issue Oct 13, 2020
The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: hashicorp/terraform-provider-google#1962, hashicorp/terraform-provider-google#1817, hashicorp/terraform-provider-google#7391
slevenick pushed a commit that referenced this issue Oct 14, 2020
The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration. 

Related: #1962, #1817, #7391
slevenick added a commit to GoogleCloudPlatform/magic-modules that referenced this issue Oct 14, 2020
* GKE documentation recommends default oauth scope

The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: hashicorp/terraform-provider-google#1962, hashicorp/terraform-provider-google#1817, hashicorp/terraform-provider-google#7391

* Add note to node_config.oauth_scopes pointing to official docs

Co-authored-by: tshak <[email protected]>
modular-magician added a commit to modular-magician/terraform-provider-google-beta that referenced this issue Oct 14, 2020
* GKE documentation recommends default oauth scope

The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: hashicorp/terraform-provider-google#1962, hashicorp/terraform-provider-google#1817, hashicorp/terraform-provider-google#7391

* Add note to node_config.oauth_scopes pointing to official docs

Co-authored-by: tshak <[email protected]>
Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit to hashicorp/terraform-provider-google-beta that referenced this issue Oct 14, 2020
* GKE documentation recommends default oauth scope

The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: hashicorp/terraform-provider-google#1962, hashicorp/terraform-provider-google#1817, hashicorp/terraform-provider-google#7391

* Add note to node_config.oauth_scopes pointing to official docs

Co-authored-by: tshak <[email protected]>
Signed-off-by: Modular Magician <[email protected]>

Co-authored-by: tshak <[email protected]>
modular-magician added a commit to modular-magician/terraform-provider-google that referenced this issue Oct 14, 2020
* GKE documentation recommends default oauth scope

The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: hashicorp#1962, hashicorp#1817, hashicorp#7391

* Add note to node_config.oauth_scopes pointing to official docs

Co-authored-by: tshak <[email protected]>
Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit that referenced this issue Oct 14, 2020
* GKE documentation recommends default oauth scope

The `oauth_scopes` section of `google_container_cluster` has generated a lot of confusion since GCP [no longer uses access scopes](https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes). The [best practice](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#best_practices) is to use the `https://www.googleapis.com/auth/cloud-platform` scope and constrain permissions at the service account level. As currently documented, the examples guide the developer down the path of using legacy access scopes. This PR updates the documentation with the recommended configuration.

Related: #1962, #1817, #7391

* Add note to node_config.oauth_scopes pointing to official docs

Co-authored-by: tshak <[email protected]>
Signed-off-by: Modular Magician <[email protected]>

Co-authored-by: tshak <[email protected]>
@upodroid
Copy link
Contributor

upodroid commented Feb 4, 2021

@rileykarson We can close this issue. It was fixed in #7441

@ghost
Copy link

ghost commented Mar 8, 2021

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!

@ghost ghost locked as resolved and limited conversation to collaborators Mar 8, 2021
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

5 participants