Data resource for Service Account fails to find default token #1104
Comments
|
@servo1x Have you found any workaround for this issue? |
|
The problem is with the 3 seconds check performed in the below line. Can we have it increased to a bigger limit, may be 60 seconds? If we have mutation webhooks, the secret creation can take longer. |
Increased service_account and secret creation_time difference check to a bigger limit, 60 seconds; instead of 3 seconds. If we have mutation webhooks, the secret creation can take longer. hashicorp#1104
Increased service_account and secret creation_time difference check to a bigger limit, 60 seconds; instead of 3 seconds. If we have mutation webhooks, the secret creation can take longer. hashicorp#1104
|
@wjam, @alexsomesan why do we have that time check in the first place (#377)? |
|
To be able to identify which token was the default one |
|
Why not use the |
|
Then that secret would not be the default one as defined by the documentation.
|
|
Note that the PR you linked to was just for adding support to import a service account and nothing more |
|
But why do we use |
|
Because import has to deal with the fact that there may be many secrets associated with the service account and it needs to discover which the 'default' one was - which the create operation has already defined as the secret that was created alongside the service account. I would argue that the |
@wjam Doesn't it impact |
|
No, PR #377 is about adding support for importing service accounts. |
|
Thanks. We have found the following snippet failing. |
|
Okay. But remember, the PR I raised didn't touch this - review the PR and you can see that it doesn't touch the data source. Adding the service account data source was PR #731. |
|
Got it. I had another PR raised 20 days ago to mitigate it. #1165 |
|
Team, will this work be moved? Basic sa account lookup fails. The whole data source
|
|
I am also stuck with this. Seems like the motivation for 3 seconds was not entirely random, but I also really need this PR merged so I can get past this issue. |
|
Thinking about null provider with local-exec to get shell -> kubectl up and running. That should work, ideally. |
|
Thx @rossdotpink because of that link i checked my nodes for clock drift... and indeed one of them was off just enough to cause the problem. |
|
We are hitting similar issue; we create ~200 namespaces and their own service accounts at once; this creates queue and 3 seconds isn't enough. Usage: data "kubernetes_service_account" "this" {
metadata {
namespace = kubernetes_service_account.this.metadata.0.namespace
name = kubernetes_service_account.this.metadata.0.name
}
}
data "kubernetes_secret" "this" {
metadata {
namespace = kubernetes_service_account.this.metadata.0.namespace
name = data.kubernetes_service_account.this.default_secret_name
}
}With error: A workaround is to manually delete SA and let TF re-create it again - without the "queue"... |
|
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, Provider Version and Kubernetes Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applyapply fails because of differing creation timestampsExpected Behavior
A valid service token should be found regardless of creation timestamp drift.
Actual Behavior
When a service account default token gets rotated, the new secret has a different timestamp and Terraform is unable to find the default token.
References
Community Note
The text was updated successfully, but these errors were encountered: