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
Default secret no longer being generated for service account, with Kubernetes 1.24.0 #1724
Comments
Have encountered this problem too, not possible to use the provider with Going to look at converting my resources related to this issue into a Helm chart instead for the time being. |
If you can't downgrade your cluster, you can use
|
We at SAS have run into this problem when attempting to create a managed K8s 1.24.0 cluster in Azure using the following versions. Terraform version: v1.0.0 │ Error: Waiting for default secret of "kube-system/hehewl-1-cluster-admin-sa" to appear Downgrading K8s isn't an option for us as the goal of our work is to use K8s 1.24.x. We will consider if the proposed work around is viable for our work. This issue hasn't been updated in some time. Is there any new information on the situation and when it might be addressed? |
@alexsomesan has submitted a fix already in commit c178cdc but it seems like his solution doesn't work completely. The mentioned commit is included in the actual 2.11. |
The changes for this PR, #1634 were working under the assumption that there is a default secret for a Service Account. There is no longer a default secret in K8s 1.24. |
Yes, you‘re right. The PR has nothing to do with the changed behavior in k8s 1.24 |
Is there any update on this? GKE now has 1.24 available in preview, but I cannot use terraform to install it. I'm seeing the same issue, │ Error: Waiting for default secret of "kube-system/hehewl-3-cluster-admin-sa" to appear |
Can his be changed to include a bug label please? |
By default, `kind` would install a node image for Kubernetes 1.24, which is a couple minor versions past what we deploy to cloud environments and which runs afoul of some Terraform bugs[1]. Pin the Kind node image we use to a Kubernetes 1.22 image, to match the Kind we use in other CI contexts. [1]: hashicorp/terraform-provider-kubernetes#1724
The problem when generating new service accounts, is that the secret containing the SA token is no longer generated automatically since the LegacyServiceAccountTokenNoAutoGeneration function gate was enabled as true in Kubernetes clusters version 1.24. (references: kubernetes/enhancements#2799 https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) This is the reported issue for the terraform resource kubernetes_service_account hashicorp/terraform-provider-kubernetes#1724 Alternative changes were made using the terraform resource kubernetes_manifest to manually generate the service accounts along with their secret
The problem when generating new service accounts, is that the secret containing the SA token is no longer generated automatically since the LegacyServiceAccountTokenNoAutoGeneration feature gate was enabled as true in Kubernetes clusters version 1.24. (references: kubernetes/enhancements#2799 https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) This is the reported issue for the terraform resource kubernetes_service_account hashicorp/terraform-provider-kubernetes#1724 Alternative changes were made using the terraform resource kubernetes_manifest to manually generate the service accounts along with their secret
By default, `kind` would install a node image for Kubernetes 1.24, which is a couple minor versions past what we deploy to cloud environments and which runs afoul of some Terraform bugs[1]. Pin the Kind node image we use to a Kubernetes 1.22 image, to match the Kind we use in other CI contexts. We also make sure to install the `kind` CLI ourselves in the CI workflow, to guarantee that the node image we pin comes from the same release. [1]: hashicorp/terraform-provider-kubernetes#1724
By default, `kind` would install a node image for Kubernetes 1.24, which is a couple minor versions past what we deploy to cloud environments and which runs afoul of some Terraform bugs[1]. Pin the Kind node image we use to a Kubernetes 1.22 image, to match the Kind we use in other CI contexts. We also make sure to install the `kind` CLI ourselves in the CI workflow, to guarantee that the node image we pin comes from the same release. [1]: hashicorp/terraform-provider-kubernetes#1724
So as @hahewlet stated above we're now seeing this on Azure and GCP. AWS has not released k8s 1.24 at this time, so no word if there's a problem there. Can someone look at addressing this as it's a major change for those moving from k8s 1.23 -> 1.24 This will cause issues with folks depending on the default_secret. Thx in advance. |
Observing this issue in local clusters using the latest k3s version as well. |
Is there any plan on how this could/should be fixed in the provider? |
Service account can not be created for 1.24 cluster. Bug details and discussion could be foud [in this thread](hashicorp/terraform-provider-kubernetes#1724)
…bernetes 1.24.0 (hashicorp#1724) Because of k8s version 1.24 the default token will not be generated. `The LegacyServiceAccountTokenNoAutoGeneration feature gate is beta, and enabled by default. When enabled, Secret API objects containing service account tokens are no longer auto-generated for every ServiceAccount.` https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#urgent-upgrade-notes The check of the service account count is wong assuming that it has always a default token.
|
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. |
Terraform version, Kubernetes provider version and Kubernetes version
Terraform configuration
Original version:
Updated version:
Question
I'm converting some yaml-files to Terraform and have found an issue I can't seem to get around.
I'm creating a service account, which worked find when using kubectl. However, through Terraform I just get error like
Waiting for default secret of "debugging/serviceaccount" to appear
.With debug output on, I see
Configuration contains 0 secrets, saw 0, expected 1
repeated several times before the apply fails.I see that since Kubernetes 1.24.0, service accounts no longer get this secret automatically generated (with or without automount_service_account_token set). I've tried the recommended new way of doing this (updated version above), but it still fails as before.
Kubernetes 1.24.0 release notes with original issue
When looking at this code:
terraform-provider-kubernetes/kubernetes/resource_kubernetes_service_account.go
Line 121 in 6c2b7fe
... it seems a service account cannot go through without a secret being "magically" added behind the scenes. Is this a bug/regression when using Kubernetes 1.24.0, or am I missing something?
Some additional info
I sometimes also see this error, but not always:
Sometimes the secrets are created as they should, other times the apply exits before all resources are deployed. When everything is in fact deployed, everything works as it should with the application - it's just the deployment which fails.
The text was updated successfully, but these errors were encountered: