-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
fix: issue with kubernetes_service_account in k8s 1.24 #1329
fix: issue with kubernetes_service_account in k8s 1.24 #1329
Conversation
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
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @yasserisa
modules/workload-identity/main.tf
Outdated
@@ -45,16 +44,45 @@ resource "google_service_account" "cluster_service_account" { | |||
project = var.project_id | |||
} | |||
|
|||
resource "kubernetes_service_account" "main" { | |||
resource "kubernetes_manifest" "main_secret" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the manifest resource has a limitation which requires the cluster to be available at plan time. We may have to look at other alternatives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a very good point.
I found a community module that might solve the problem.
https://registry.terraform.io/providers/gavinbunney/kubectl/latest
Another alternative I was thinking about is that we occupy a script using this module
@yasserisa |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yasserisa Looks like there is some movement in the provider to fix this. Since this will be a breaking change if we switch to wrapper I am leaning towards waiting a bit to see if the fix will help.
I have seen that the PR was generated yesterday to fix the problem. hashicorp/terraform-provider-kubernetes#1792 I agree to wait, as I saw in the PR, the |
hashicorp/terraform-provider-kubernetes#1792 was merged so I am closing this. We may need to constrain the provider to new min version once released. |
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