-
Notifications
You must be signed in to change notification settings - Fork 184
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.
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
Read secrets for client-onboarding-token-validation #2827
base: main
Are you sure you want to change the base?
Conversation
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
a suggestion, we are seeing this PR for third time, second time it's fine that you weren't able to recover GH (remember you can't create new a/c every-time though) but last time it's better if you can focus on rebasing properly. yes, GH doesn't have any issue w/ closing & opening a new PR but for reviewers it's kinda hard to relook from the start. |
674b54c
to
dc8a56b
Compare
I have tested this PR, with the latest 4.18 build. I could see the keys getting exchanged when the rotate signing key is clicked in storageclient page. |
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
|
@@ -225,7 +225,7 @@ func (r *StorageClusterReconciler) SetupWithManager(mgr ctrl.Manager) error { | |||
Owns(&appsv1.Deployment{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Service{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.ConfigMap{}, builder.MatchEveryOwner, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Secret{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Secret{}, builder.MatchEveryOwner, builder.WithPredicates(predicate.GenerationChangedPredicate{})). |
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.
Why do we need a MatchEveryOwner here? Isn't StorageCluster the controller owner of the secret we want to watch?
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.
controller owner reference set to secrets, ack
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 comment was not addressed as tall! You are matching by controller ownership, it does not make sense to match every owner
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.
Owner reference were set during creation of secrets in on-boarding job, when the rotate signing key is clicked the re-consiliation is not happening, The onboarding-token needs to be created which is failing.
Any suggestion for this issue.
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.
If there is a controller owner ref on the secret and then someone deletes that secret then a delete event will be sent here. And because the item had an owner ref (with controller set) then a reconcile request will be queued. Now if that is not happening there can be a bug in a couple of places:
- The predicate might be the one the drops the event (should not, but might be)
- The reconcile is initiated but the reconcile code might not re-create the secret (might happen because of stale cache)
- Are we sure we are adding a controller reference on the secret? if not and we are only adding an owner ref then that is your bug
@mrudraia1 You need to identify the issue, and only after you fully understand what is going on you can suggest a fix.
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.
StorageCluster is the owner of the secrets, not the controller owner here
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mrudraia1 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
4dac720
to
8198c71
Compare
ecddbf0
to
d31f826
Compare
infra issue |
@@ -225,7 +225,7 @@ func (r *StorageClusterReconciler) SetupWithManager(mgr ctrl.Manager) error { | |||
Owns(&appsv1.Deployment{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Service{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.ConfigMap{}, builder.MatchEveryOwner, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Secret{}, builder.WithPredicates(predicate.GenerationChangedPredicate{})). | |||
Owns(&corev1.Secret{}, builder.MatchEveryOwner, builder.WithPredicates(predicate.GenerationChangedPredicate{})). |
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 comment was not addressed as tall! You are matching by controller ownership, it does not make sense to match every owner
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
e627033
to
bbae1f7
Compare
bbae1f7
to
36162f4
Compare
36162f4
to
e3bba8e
Compare
e3bba8e
to
f6ee295
Compare
controllers/util/provider.go
Outdated
} | ||
|
||
Block, _ := pem.Decode(pemString) | ||
Block, _ := pem.Decode(privateSecretKey) |
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.
We should not ignore decode errors. What if the key is corrupted?
services/ux-backend/handlers/onboarding/clienttokens/handler.go
Outdated
Show resolved
Hide resolved
4f84a13
to
64dfa2f
Compare
8fbaa53
to
8d4a61d
Compare
Signed-off-by: Mrudraia1 <mrudraia@redhat.com>
8d4a61d
to
1a8e140
Compare
This PR reads the secrets instead of reading the secrets from the volume mounts.
whenever the new onboarding secrets are created, it takes more time to read the secrets from the volume mounts,
The user clicks the rotate onboarding keys, the kubernetes still uses the old public, private keys , the new keys are mounted later, So this PR will read the secrets directly from the kubernetes secrets.