Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix: Always create manual long lived token #19970

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

fix: Always create manual long lived token #19970

wants to merge 5 commits into from
+125 −124

Conversation

VannTen
Copy link
Contributor

@VannTen VannTen commented Sep 17, 2024 •
edited
Loading

Argocd should use explicitly created long-lived token, not the automatic ones created when a service account is created (on cluster with kubernetes version < 1.24).

Furthermore, it should not add itself the secrets it creates to the secrets array on the service account, because this makes kubernetes think this is an automated secret.

See : https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#create-token
Fixes #16859

Checklist:

  • Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
  • The title of the PR states what changed and the related issues number (used for the release note).
  • The title of the PR conforms to the Toolchain Guide
  • I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
  • I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
  • Does this PR require documentation updates?
  • I've updated documentation as required by this PR.
  • I have signed off all my commits as required by DCO
  • I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • My build is green (troubleshooting builds).
  • My new feature complies with the feature status guidelines.
  • I have added a brief description of why this PR is necessary and/or what this PR solves.
  • Optional. My organization is added to USERS.md.
  • Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

@VannTen VannTen requested a review from a team as a code owner September 17, 2024 19:43
@bunnyshell Bunnyshell
Copy link

bunnyshell bot commented Sep 17, 2024 •
edited
Loading

✅ Preview Environment deployed on Bunnyshell

Component Endpoints
argocd https://argocd-t4mqgj.bunnyenv.com/
argocd-ttyd https://argocd-web-cli-t4mqgj.bunnyenv.com/

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

  • 🔴 /bns:stop to stop the environment
  • 🚀 /bns:deploy to redeploy the environment
  • ❌ /bns:delete to remove the environment

@bunnyshell Bunnyshell
Copy link

bunnyshell bot commented Sep 17, 2024

✅ Preview Environment created on Bunnyshell but will not be auto-deployed

See: Environment Details

Available commands (reply to this comment):

  • 🚀 /bns:deploy to deploy the environment

@VannTen VannTen force-pushed the fix/always_manual_long_lived_token branch from 55fb526 to cb33bf0 Compare September 17, 2024 19:47
gdsoumya
gdsoumya requested changes Sep 18, 2024
View reviewed changes
util/clusterauth/clusterauth.go Outdated
secret := &corev1.Secret{
ObjectMeta: metav1.ObjectMeta{
GenerateName: serviceAccount.Name + "-token-",
Namespace: serviceAccount.Namespace,
Name: sa + "-long-lived-token",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we do something like, that would make it even more obvious and specific imo.

Suggested change
Name: sa + "-long-lived-token",
Name: sa + ".argocd.token",

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about that, IMO the SA and the token are an unit, and I the user change the name of the service account (default "argocd-manager") I don't think we should override that decision in the token. OTOH if it's worththile to add a suffix / prefix, I think the SA name should be the place to do that.

Wdyt ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you see my suggested change I meant to add that as a suffix to the sa and not just that as the secret name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I've seen that. What I mean is that the relation to argocd is already encoded into the service account name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The location of the string has changed (I pulled it in a constant to avoid typo), but the discussion is still relevant

@VannTen
Copy link
Contributor Author

VannTen commented Sep 18, 2024 via email •
edited
Loading

@VannTen VannTen force-pushed the fix/always_manual_long_lived_token branch 2 times, most recently from 616a6fe to d94dc7e Compare September 18, 2024 12:13
@VannTen VannTen marked this pull request as draft September 18, 2024 12:27
@VannTen
Copy link
Contributor Author

VannTen commented Sep 18, 2024

It looks like the fake.NewClientset does not update secrets annotated with the serviceaccount annotation with a token. Which is probably coherent with it's documentation.
I'm looking how to resolve that, maybe there is a way to add a mini pseudo-controller to the fake clientset (that sounds wrong... 😄 )

@VannTen VannTen force-pushed the fix/always_manual_long_lived_token branch from 9308949 to 548c42a Compare September 19, 2024 09:26
@VannTen
Copy link
Contributor Author

VannTen commented Sep 19, 2024 •
edited
Loading

The -race failure appears unrelated, AFAICT (permissions errors in repository/ tests)
Is there a way to re-trigger tests without re-pushing ?

@VannTen VannTen marked this pull request as ready for review September 19, 2024 09:50
@codecov Codecov
Copy link

codecov bot commented Sep 19, 2024 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (master@1fcbcc1). Learn more about missing BASE report.
Report is 2 commits behind head on master.

Additional details and impacted files 
@@            Coverage Diff            @@
##             master   #19970   +/-   ##
=========================================
  Coverage          ?   55.79%           
=========================================
  Files             ?      320           
  Lines             ?    44364           
  Branches          ?        0           
=========================================
  Hits              ?    24754           
  Misses            ?    17048           
  Partials          ?     2562

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@VannTen
use constant in secret data key
b1291d5 
Signed-off-by: Max Gautier <[email protected]>
@VannTen
Do not patch serviceAccount with created secret
68ac178 
Referencing the secrets in the `secrets` fields of the ServiceAccount
will make kubernetes consider it an auto-generated secret, and:
1. Warn about its usage in API responses
2. Subject it to automatic cleanup after roughly one year if unused

See:
- https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#legacy-serviceaccount-token-cleaner
- https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#create-token

Signed-off-by: Max Gautier <[email protected]>
@VannTen
Do not use existing auto-generated tokens
a3c8ea1 
Kubernetes legacy ServiceAccount tokens will generate warnings on use
and be garbage collected if not used for one year, starting with
Kubernetes 1.30.

Use an explicitly created token secret with a fixed name, based on the
service account name.

Signed-off-by: Max Gautier <[email protected]>
@VannTen
clusterauth: rework tests
99a4a7a 
This align clusterauth_test with the expected behavior modified by the
previous commit, and is more in line with the way Kubernetes service
account secrets are handled by the token controller.

Signed-off-by: Max Gautier <[email protected]>
@VannTen VannTen force-pushed the fix/always_manual_long_lived_token branch 3 times, most recently from c14c48d to 4dbab57 Compare September 19, 2024 14:45
@VannTen
clusterauth: rewrite getOrCreate testing
c2634ec 
Test all 3 cases:
- token secret already exists -> we should not create another
- token secret does not exists
- error on secret creation.

Since getOrCreateServiceAccountSecretToken does not actually look at the
content of the token itself, we remove the part of the test related to
this.

Signed-off-by: Max Gautier <[email protected]>
@VannTen VannTen force-pushed the fix/always_manual_long_lived_token branch from 4dbab57 to c2634ec Compare September 19, 2024 15:00
@VannTen
Copy link
Contributor Author

VannTen commented Sep 19, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gdsoumya gdsoumya Awaiting requested review from gdsoumya

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Log Spam/Sorta Infinite Loop?
2 participants
@VannTen @gdsoumya