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

[TK-1373] Update resource and data of 'kubernetes_(default_)service_account' to handle deprecated 'default_secret_name' in Kubernetes 1.24.0+ #1792

Merged
merged 5 commits into from
Aug 18, 2022

Conversation

arybolovlev
Copy link
Contributor

@arybolovlev arybolovlev commented Jul 26, 2022

Description

Starting from the version 1.24.0 Kubernetes does not generate a token for a service account by default(link to the change log). In this case, the concept of default_secret_name is not applicable anymore for the Kubernetes clusters v1.24.0+. This PR updates the provider's behavior accordingly to the cluster version.

Affected resource

  • r/kubernetes_default_service_account
  • d/kubernetes_service_account
  • r/kubernetes_service_account

Acceptance tests

  • Have you added an acceptance test for the functionality being added?
  • Have you run the acceptance tests on this branch?

Output from acceptance testing:
1.24.0+ [1.24.2-gke.300]

$ make testacc TESTARGS='-run ^.*ServiceAccount.*'

=== RUN   TestAccKubernetesDataSourceServiceAccount_basic
--- PASS: TestAccKubernetesDataSourceServiceAccount_basic (10.21s)
=== RUN   TestAccKubernetesDataSourceServiceAccount_default_secret
    provider_test.go:225: This test does not run on cluster versions 1.24.0 and above
--- SKIP: TestAccKubernetesDataSourceServiceAccount_default_secret (0.06s)
=== RUN   TestAccKubernetesDefaultServiceAccount_basic
--- PASS: TestAccKubernetesDefaultServiceAccount_basic (13.19s)
=== RUN   TestAccKubernetesDefaultServiceAccount_secrets
--- PASS: TestAccKubernetesDefaultServiceAccount_secrets (12.79s)
=== RUN   TestAccKubernetesDefaultServiceAccount_automountServiceAccountToken
--- PASS: TestAccKubernetesDefaultServiceAccount_automountServiceAccountToken (13.20s)
=== RUN   TestAccKubernetesServiceAccount_basic
--- PASS: TestAccKubernetesServiceAccount_basic (6.58s)
=== RUN   TestAccKubernetesServiceAccount_default_secret
    provider_test.go:225: This test does not run on cluster versions 1.24.0 and above
--- SKIP: TestAccKubernetesServiceAccount_default_secret (0.06s)
=== RUN   TestAccKubernetesServiceAccount_automount
--- PASS: TestAccKubernetesServiceAccount_automount (5.64s)
=== RUN   TestAccKubernetesServiceAccount_update
--- PASS: TestAccKubernetesServiceAccount_update (13.58s)
=== RUN   TestAccKubernetesServiceAccount_generatedName
--- PASS: TestAccKubernetesServiceAccount_generatedName (5.08s)
PASS

pre-1.24.0 [1.23.8-gke.400]

$ make testacc TESTARGS='-run ^.*ServiceAccount.*'

=== RUN   TestAccKubernetesDataSourceServiceAccount_basic
--- PASS: TestAccKubernetesDataSourceServiceAccount_basic (8.83s)
=== RUN   TestAccKubernetesDataSourceServiceAccount_default_secret
--- PASS: TestAccKubernetesDataSourceServiceAccount_default_secret (8.08s)
=== RUN   TestAccKubernetesDefaultServiceAccount_basic
--- PASS: TestAccKubernetesDefaultServiceAccount_basic (12.[30](https://github.com/hashicorp/terraform-provider-kubernetes/runs/7520903353?check_suite_focus=true#step:11:31)s)
=== RUN   TestAccKubernetesDefaultServiceAccount_secrets
--- PASS: TestAccKubernetesDefaultServiceAccount_secrets (11.76s)
=== RUN   TestAccKubernetesDefaultServiceAccount_automountServiceAccountToken
--- PASS: TestAccKubernetesDefaultServiceAccount_automountServiceAccountToken (12.11s)
=== RUN   TestAccKubernetesServiceAccount_basic
--- PASS: TestAccKubernetesServiceAccount_basic (5.86s)
=== RUN   TestAccKubernetesServiceAccount_default_secret
--- PASS: TestAccKubernetesServiceAccount_default_secret (5.[36](https://github.com/hashicorp/terraform-provider-kubernetes/runs/7520903353?check_suite_focus=true#step:11:37)s)
=== RUN   TestAccKubernetesServiceAccount_automount
--- PASS: TestAccKubernetesServiceAccount_automount (5.21s)
=== RUN   TestAccKubernetesServiceAccount_update
--- PASS: TestAccKubernetesServiceAccount_update (12.14s)
=== RUN   TestAccKubernetesServiceAccount_generatedName
--- PASS: TestAccKubernetesServiceAccount_generatedName (4.81s)
PASS

Release Note

Release note for CHANGELOG:

...

References

Fixes: 1724

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

@arybolovlev arybolovlev force-pushed the update-svc-account-behaviour-1.24 branch from ca74686 to 0cdf886 Compare July 26, 2022 11:52
Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nicely done!
I left a comment about how we surface the changed behaviour to users so that they are not caught off-guard by the missing default token.

@@ -633,3 +634,26 @@ func useAdmissionregistrationV1beta1(conn *kubernetes.Clientset) (bool, error) {
useadmissionregistrationv1beta1 = ptrToBool(true)
return true, nil
}

func getServerVersion(connection *kubernetes.Clientset) (*gversion.Version, error) {
sv, err := connection.ServerVersion()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We make use of this over here too:

serverVersion, err := conn.ServerVersion()

Might be worth trying to unify the two.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, made a small improvement. 👍🏻

if err != nil {
return diag.FromErr(err)
}
d.Set("default_secret_name", secret.Name)
if b {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Silently skipping setting any value on default_secret_name might be confusing to users with existing configurations.
I would suggest returning a Warning level Diagnostic when we do this, to alert users in the Terraform output about the new behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated the logic and moved the condition statement that verifies the version a bit lower. Now we should get a warning when creating or updating any of r/kubernetes_default_service_account, d/kubernetes_service_account, and r/kubernetes_service_account, however, when we do the import for r/kubernetes_service_account -- we don't get a warning message, because import expects only an error as return, and this is not an error.

@arybolovlev arybolovlev force-pushed the update-svc-account-behaviour-1.24 branch from 0cdf886 to 646c065 Compare July 26, 2022 13:12
… handle deprecated 'default_secret_name' in Kubernetes 1.24.0+
@arybolovlev arybolovlev force-pushed the update-svc-account-behaviour-1.24 branch from 646c065 to d732153 Compare July 26, 2022 13:53
@arybolovlev arybolovlev marked this pull request as ready for review July 26, 2022 14:08
@flokli
Copy link

flokli commented Jul 27, 2022

I applied this patch on top of terraform-provider-kubernetes, and am successfully able to create kubernetes_service_account resources again, so that works, thanks :-)

I however noted I always get the "Warning: 'default_secret_name' is no longer applicable for Kubernetes 'v1.24.0' and above" warning when creating a kubernetes_service_account resource, not only in case the attribute is used. Is that expected?

@arybolovlev arybolovlev changed the title Update resource and data of 'kubernetes_(default_)service_account' to handle deprecated 'default_secret_name' in Kubernetes 1.24.0+ [TK-1373] Update resource and data of 'kubernetes_(default_)service_account' to handle deprecated 'default_secret_name' in Kubernetes 1.24.0+ Aug 9, 2022
@yuriy-yarosh
Copy link

@alexsomesan hopefully this will be merged soon-ish™

Copy link
Collaborator

@jrhouston jrhouston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this @arybolovlev – I've approved but left a couple of cosmetic comments.

kubernetes/resource_kubernetes_service_account.go Outdated Show resolved Hide resolved
kubernetes/resource_kubernetes_service_account.go Outdated Show resolved Hide resolved
kubernetes/resource_kubernetes_service_account.go Outdated Show resolved Hide resolved
@arybolovlev arybolovlev force-pushed the update-svc-account-behaviour-1.24 branch from cee34c6 to 8caf26c Compare August 16, 2022 14:03
@arybolovlev
Copy link
Contributor Author

I applied this patch on top of terraform-provider-kubernetes, and am successfully able to create kubernetes_service_account resources again, so that works, thanks :-)

I however noted I always get the "Warning: 'default_secret_name' is no longer applicable for Kubernetes 'v1.24.0' and above" warning when creating a kubernetes_service_account resource, not only in case the attribute is used. Is that expected?

I would say this is a trade-off now. In the case of the managed Kubernetes cluster solution, this new behavior might not be delivered to the users and they might not be aware of it. So it can be a source of confusion when the provider does not produce desired output anymore. The same behavior you may observe with other tools in the Kubernetes world. They keep repeating the same warning or deprecation message a long time before it actually happens to make sure that everyone is aware of it.

I hope that explanation makes sense. 😊

Thank you!

@flokli
Copy link

flokli commented Aug 18, 2022

I applied this patch on top of terraform-provider-kubernetes, and am successfully able to create kubernetes_service_account resources again, so that works, thanks :-)
I however noted I always get the "Warning: 'default_secret_name' is no longer applicable for Kubernetes 'v1.24.0' and above" warning when creating a kubernetes_service_account resource, not only in case the attribute is used. Is that expected?

I would say this is a trade-off now. In the case of the managed Kubernetes cluster solution, this new behavior might not be delivered to the users and they might not be aware of it. So it can be a source of confusion when the provider does not produce desired output anymore. The same behavior you may observe with other tools in the Kubernetes world. They keep repeating the same warning or deprecation message a long time before it actually happens to make sure that everyone is aware of it.

I hope that explanation makes sense. blush

Thank you!

I don't see how this explanation is related - the code is not using the default_secret_name attribute, so why is it showing a warning?

@arybolovlev arybolovlev merged commit e7485b7 into main Aug 18, 2022
@arybolovlev arybolovlev deleted the update-svc-account-behaviour-1.24 branch August 18, 2022 14:14
BBBmau pushed a commit that referenced this pull request Aug 31, 2022
…ccount' to handle deprecated 'default_secret_name' in Kubernetes 1.24.0+ (#1792)

* Update resource and data of 'kubernetes_(default_)service_account' to handle deprecated 'default_secret_name' in Kubernetes 1.24.0+
@github-actions
Copy link

I'm going to lock this pull request 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 related to this change, 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 Sep 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default secret no longer being generated for service account, with Kubernetes 1.24.0
5 participants