Skip to content

Resource google_container_cluster always enables legacy authorization #1116

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

Closed
mrparkers opened this issue Feb 21, 2018 · 3 comments
Closed

Comments

@mrparkers
Copy link
Contributor

I'm not sure if this would be classified as a bug, but I was advised by @paddycarver to report it.

According to the GKE docs, GKE clusters with a version of 1.8 or higher will have legacy authorization disabled by default. Reference:

Kubernetes Engine clusters running Kubernetes version 1.8 and later disable the legacy authorization system by default, and thus role-based access control permissions take effect with no special action required.

However, it looks like this resource will always enable legacy authorization by default, regardless of the k8s version used: https://github.com/terraform-providers/terraform-provider-google/blob/master/google/resource_container_cluster.go#L160.

Also, the docs for this resource don't specify that the default value for the enable_legacy_abac argument is true: https://www.terraform.io/docs/providers/google/r/container_cluster.html#enable_legacy_abac

I suppose the fix for this would be to make the default value of the enable_legacy_abac argument depend on the value of node_version. I'm not sure if it makes sense for the provider to use different default values for this argument depending on another argument, but that is the behavior I was expecting as a user.

I'll happily submit a PR for whatever change that seems to be the most appropriate.

@danawillow
Copy link
Contributor

Hey @mrparkers, reporting this was exactly the right thing to do- even if it's not a bug per se, it's still behavior that you were surprised about, which means we can do better.

Unfortunately, your idea of making the default value depend on the value of node_version isn't actually possible. The default is something that gets set schema-side, but we don't have access to the value of other fields at the time we set the default.

Normally when fields have defaults that we don't know about ahead of time, we would set them to Computed and call it a day. However, if we set a boolean to computed then users can't ever change it from true to false (because false is equivalent to unset, and unset computed values mean "just read whatever is set server-side"). This is something that I've heard rumors might change in future versions of HCL but I don't know all the changes nor their timeline so we shouldn't rely on that.

Our best option in this case then is going to be to change the docs. The question then becomes whether the default should remain true or change to false. My guess is that it should probably change to false, but I'm definitely not an expert. If you think that's the way to go though feel free to send a PR my way (it can be the same one that updates the docs to include the default).

Thanks!

@mrparkers
Copy link
Contributor Author

Hi @danawillow, thanks for the response. I think it would probably make sense to have legacy authorization default to false going forward, since GKE defaults to using a version higher than 1.8, which would normally have this disabled when creating it using the GCP console.

I will submit a PR for this and a change to the docs some time this weekend.

Thanks!

@ghost
Copy link

ghost commented Nov 18, 2018

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 and limited conversation to collaborators Nov 18, 2018
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

2 participants