fix #2271: Refresh token every minute

[Vlatombe]

Description

Should address #2271.
Platforms such as Amazon EKS since 1.21 rely on BoundServiceAccountTokenVolume to have time-limited access tokens. It is expected from kubernetes client implementations to refresh the configuration periodically to get a new token.

From kubernetes 1.21 release notes

Clients should reload the token from disk periodically (once per minute is recommended) to ensure they continue to use a valid token. k8s.io/client-go version v11.0.0+ and v0.15.0+ reload tokens automatically.

Prior work from #3105 addressed it once the token expired, however it doesn't address the current situation where the token is actually valid for 90 days, but expected to be refreshed at least every hour. This triggers audit logs events in AWS which can lead users to think their client will break once the token really expires.

This introduces a proactive aproach of refreshing the token from disk if the current token has been retrieved more than one minute ago.

For oidc implementation, I'm not knowledgeable enough to determine whether a more optimal solution could be implemented using some alternate validity timestamp.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

84.6% Coverage
0.0% Duplication

[Vlatombe]

@manusa Would it be possible to get a review on this work?

[manusa]

Yes, this is the next one going in, should be out in next 6.1.0 (with maybe some follow-ups too)

[apiwoni]

I think this is more of a brute force approach to refresh service account token. Could we attempt to test for recommended expires_in before preemptively refreshing token or just let it fail and then refresh access token and retry?

[manusa]

thread continues here: #2271 (comment)