Remove association between ServiceAccounts and token Secrets #884
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tpantelis
requested review from
Jaanki,
Oats87,
skitt and
sridhargaddam
as code owners
|
🤖 Created branch: z_pr884/tpantelis/sa_secret |
If a token Secret is associated to a ServiceAccount via its "secrets" field, K8s 1.27 interprets this as an auto-generated token and issues a client-side warning: "Use tokens from the TokenRequest API or manually created secret-based tokens instead of auto-generated secret-based tokens." While we no longer use auto-generated Secrets, we do still set the "secrets" field with the manually created Secret which causes the warning to be generated for every API call issued using a rest config created with the Secret's token. We don't need to set the "secrets" field - we can locate a ServiceAccount's associated Secret via the "kubernetes.io/service-account.name" annotation on the Secret. For migration, also remove the "secrets" field from existing ServiceAccounts. As a further safeguard on upgrade, ignore the warning via the warning handler. Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
We don't need them created for the pod ServiceAccounts. Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
...to serviceaccount.GetTokenSecretFor as the function isn't really related to RBAC. Plus we already have unit tests in serviceaccount so we get code coverage credit :) Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
skitt
approved these changes
Aug 29, 2023
dfarrell07
approved these changes
Aug 29, 2023
|
🤖 Closed branches: [z_pr884/tpantelis/sa_secret] |
skitt
added a commit
to skitt/submariner-operator
that referenced
this pull request
Sep 1, 2023
Since submariner-io/subctl#884, gateway service accounts no longer have associated tokens. Signed-off-by: Stephen Kitt <skitt@redhat.com>
skitt
added a commit
to submariner-io/submariner-operator
that referenced
this pull request
Sep 1, 2023
Since submariner-io/subctl#884, gateway service accounts no longer have associated tokens. Signed-off-by: Stephen Kitt <skitt@redhat.com>
dfarrell07
added
release-note-needed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a token
Secretis associated to aServiceAccountvia itssecretsfield, K8s 1.27 interprets this as an auto-generated token and issues a client-side warning:"Use tokens from the TokenRequest API or manually created secret-based tokens instead of auto-generated secret-based tokens."
While we no longer use auto-generated
Secrets, we do still set thesecretsfield with the manually createdSecretwhich causes the warning to be generated for every API call issued using a rest config created with theSecret's token.We don't need to set the
secretsfield - we can locate aServiceAccount's associated Secret via thekubernetes.io/service-account.nameannotation on theSecret.For migration, also remove the
secretsfield from existingServiceAccounts.As a further safeguard on upgrade, ignore the warning via the warning handler.
Lastly, we don't need token
Secretscreated for the podServiceAccountsso only create then for the brokerServiceAccounts.See individual commits for more details.
Fixes #880