-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add certificate watcher to queue-proxy #14189
Conversation
We want to make QP small as much as possible #9957. But the deps is enough small that we can ignore, isn't it? As far as I built the image, it seems OK. |
Good points, thank you. Yes I had the same issue with normal secrets, but projected volumes seem to work fine. But I'll probably do some more testing with it. Seems like thanos went with an approach to continuously re-read the file (thanos-io/thanos#6503) and see if there are differences. That could also work fine, but could take some more time for the certificate to be updated, so we somehow would still would need to trust multiple root CAs for some time in activator and all ingress-controllers to make it work properly - or implement proper cross signing ourselves. I still feel like that we are rebuilding too much stuff ourselves instead of leveraging functionality of a Service Mesh or directly relying on solutions like cert-manager. In the end we probably will end up with some limitations and known issues with our custom solution. |
I think your approach makes sense, seems like the path of least resistance too. Asking just so I can understand the scenario better: do you have context on why QP uses the mounted secrets? Is there a reason it doesn't have a trust-store like activator? Maybe that makes it too big, per @nak3 's point?
generally I'd agree, would it be so bad if Knative had a dependency on cert-manager? But I might not be seeing it in this case, is there a way you see cert-manager would help here? We would still need the logic to check for the change in the mounted secret, right? |
Queue-Proxy does not have access to the kube api (so no informers or watchers on secrets). Not sure what the original reasons for this are, but I also assume it is related to the size topic.
I don't think so either, especially as this would only be necessary when people want to use encryption. @evankanderson had some doubts about having that.
It would not help here directly. It is more about the rotation of the CA. Our current implementation just creates a new CA and immediately rotates all secrets. We probably will have to build some logic that does proper rotation. These things would already be handled with cert-manager. With this, ingresses, activator and proxies would have some time to shift to the new certs. |
The thanos approach is fairly easy and the introduced delay should not matter as we need to make sure we allow some rotation grace period in activator & ingress controllers anyways (reloading certs across all K Services will take some time), so I'm going to continue with that approach. Will add tests and e2e tests shortly. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #14189 +/- ##
==========================================
- Coverage 86.25% 86.11% -0.14%
==========================================
Files 199 196 -3
Lines 14811 14781 -30
==========================================
- Hits 12775 12729 -46
- Misses 1734 1746 +12
- Partials 302 306 +4
☔ View full report in Codecov by Sentry. |
/unhold This is ready to be reviewed. I'll add another issue for full CA rotation, as more work is needed to make that work (as activator and all net-* components also must support it). @dprotaso , @skonto , @nak3 , @KauzClay, @davidhadas |
I thought that the projected volumes was used for the workaround of |
The update behaviour with projectedVolumes seems to be way more stable in my tests. Do you think there is a downside to using it this way? |
/retest |
aa344e3
to
fdbb4c0
Compare
I checked this again, it takes a bit longer to refresh on disk, but in general we should be fine using a normal mount. I also checked Kube RBAC proxy, it does it the same way. Updated the PR accordingly. |
// NewCertWatcher creates a CertWatcher and watches | ||
// the certificate and key files. It reloads the contents on file change. | ||
// Make sure to stop the CertWatcher using Stop() upon destroy. | ||
func NewCertWatcher(certPath, keyPath string, reloadInterval time.Duration, logger *zap.SugaredLogger) (*CertWatcher, error) { |
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.
certPath
and keyPath
are fixed value.
We can move the const values (certPath
and keyPath)
to pkg/queue/certificate
or some common package and drop the arguments and field in the struct?
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.
Hm for now CertWatcher pretty generic (and could be used somewhere else). The constants seem to be with other configuration in sharedmain which also need to correspond to the yaml, so I think I'd prefer to let them there. WDYT?
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.
Sure, no problem. Let's keep there.
/lgtm Thank you so much 🎉 /hold for other reviewers. |
looks good to me as well! /unhold |
ah, I thought unholding this would let it be merged? Seems like it needs to be approved? Idk if I have approval power |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kvmware, ReToCode The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/unapprove |
/lgtm also |
@dprotaso can this be merged? Some Approver magic is needed. |
/assign @dprotaso |
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.
FYI - if you haven't noticed K8s is looking to provide a generic mechanism to distribute CAbundles
Though it's in early design phases
https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3257-trust-anchor-sets#pemtrustanchors-projected-volume-source
That is nice, definitely a thing that will help us. |
/lgtm |
Fixes #14187
Proposed Changes
Release Note