-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[k8s] improve kubernetes_secrets provider secret logging #6841
[k8s] improve kubernetes_secrets provider secret logging #6841
Conversation
This pull request does not have a backport label. Could you fix it @pkoutsovasilis? 🙏
|
ada501f
to
205b8f1
Compare
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
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.
LGTM
internal/pkg/composable/providers/kubernetessecrets/kubernetes_secrets.go
Outdated
Show resolved
Hide resolved
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.
Overall this looks good, just a question about why the use of backslash when golang offers a way to not have to do that.
changelog/fragments/1739437836-Improve-kubernetes_secrets-provider-secret-logging.yaml
Outdated
Show resolved
Hide resolved
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.
Missed the inline comment.
internal/pkg/composable/providers/kubernetessecrets/kubernetes_secrets.go
Outdated
Show resolved
Hide resolved
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!
I thank you for the comments 🙂 |
@cmacknz if we follow our policies this shouldn't be backported on any active releases branches. But I believe such enhancement will be helpful for users that use |
I would backport this everywhere the secrets provider implementation has changed. |
Is there a way we can get the current secret resource version agent substituted into the agent policy added into say computed-config.yaml or something? I suppose we could just log it, that might get verbose if there are a lot of secrets and/or policy changes. One of the questions I had when I was trying to debug this was, "is the secret provider working correctly but the agent somehow has a stale secret value" and I don't see anything to help me answer that. |
after looking more into running this PR actually on a k8s cluster to see how variables of
I don't see how the provider can cause this and I have already reached out to @blakerouse for support Until then let's keep this PR un-merged |
internal/pkg/composable/providers/kubernetessecrets/kubernetes_secrets.go
Outdated
Show resolved
Hide resolved
So @cmacknz I did get a hands-on experience with it. As of now, you could debug the |
created issue for one new flaky test here #6965 |
created another issue for a new flaky test here |
|
💚 Build Succeeded
History
|
created one more issue for Flaky one here. Thank you all for the reviews 🤘 |
* feat: improve kubernetes_secrets provider secret logging * feat: improve readability by replacing Info with Infof * fix: categorise properly the type of change * feat: more logging readability improvements * feat: improve readability by replacing "%s" with %q (cherry picked from commit 0ae5d35)
* feat: improve kubernetes_secrets provider secret logging * feat: improve readability by replacing Info with Infof * fix: categorise properly the type of change * feat: more logging readability improvements * feat: improve readability by replacing "%s" with %q (cherry picked from commit 0ae5d35)
* feat: improve kubernetes_secrets provider secret logging * feat: improve readability by replacing Info with Infof * fix: categorise properly the type of change * feat: more logging readability improvements * feat: improve readability by replacing "%s" with %q (cherry picked from commit 0ae5d35)
* feat: improve kubernetes_secrets provider secret logging * feat: improve readability by replacing Info with Infof * fix: categorise properly the type of change * feat: more logging readability improvements * feat: improve readability by replacing "%s" with %q (cherry picked from commit 0ae5d35)
@@ -151,7 +151,8 @@ func (p *contextProviderK8SSecrets) Fetch(key string) (string, bool) { | |||
|
|||
if p.config.DisableCache { | |||
// cache disabled - fetch secret from the API | |||
return p.fetchFromAPI(ctx, secretName, secretNamespace, secretKey) | |||
val, _, ok := p.fetchFromAPI(ctx, secretName, secretNamespace, secretKey) |
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.
@pkoutsovasilis I'm guessing that adding logging here would add too much noise?
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.
this is with cache disabled thus Fetch will always return the latest value from API server, right? we could definitely add it but since there is no intermediate layer that can bear stale secrets I thought we could try and minimise noise. What do you think? 🙂
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.
Would a debug-level log make sense?
secretKey: "secret_key_not_found", | ||
}, | ||
{ | ||
name: "key in secret not found", |
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.
Isn't this the happy path case, where the key is found?
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.
this is the almost happy path 😆 so the secret is found in the api server, there is no error reading it, but the key inside the secret we are trying to fetch doesn't exist. does it make sense?
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.
I must be missing something 😕 IIUC, the key we're looking for is secret_key
(that's what we're passing to the fetchFromAPI
function on line 978), and the mock secret we're building also has a key of secret_key
(line 974). So to me it seems like the key is found
What does this PR do?
This PR enhances the logging of the
kubernetes_secrets
provider to improve visibility into secret updates and cache operations. The changes include:fetchFromAPI
to return the resource version of a secret.fetchFromAPI
to validate secret retrieval behavior.Why is it important?
Previously, the
kubernetes_secrets
provider had minimal logging, making it difficult to determine when secrets were updated, expired, or failed to refresh. This lack of visibility led to troubleshooting challenges, especially in cases where secrets did not rotate as expected. With these improvements, users can now track secret updates more effectively without exposing sensitive values.Checklist
./changelog/fragments
using the changelog toolDisruptive User Impact
This change does not alter the core functionality of the
kubernetes_secrets
provider but improves logging. Users should see more detailed logs related to secret updates, which can be useful for debugging. There are no breaking changes expected.How to test this PR locally
Run the
kubernetes_secrets
provider unit-testsRelated issues