-
Notifications
You must be signed in to change notification settings - Fork 506
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
Suggestion/Recommendation for CVE Announcement enhancements #170
Comments
I'd be delighted to learn that there's already a good de facto standard for doing this, and that Kubernetes plans to follow that. How about an ATOM / RSS feed where you can register a webhook for notifications, with a proof-of-work / CAPTCHA required to validate the registration? Then, end users can strap anything they like onto the end of the webhook, and they can poll in case the webhook didn't arrive. (extra credit: send the webhook in CloudEvent format, maybe with a digital signature). |
I really like this idea. I would like to see more outlined for how the actual app / FaaS would be managed long term in an open way. As far as the data being collected / token exchange, where would that data be stored? How do we ensure privacy? Lastly, it would be great to have some way to easily update your Kubernetes version (in the event you patch / major upgrade). I could also see it being beneficial to receive an event "Hey, you haven't updated your version in X months/years, do you want to update or delete this alert?" |
@jimangel it sounds like you think it'd be useful for the same ATOM / RSS feed to publish all releases, whether relevant to a CVE ID or not. (?) |
I agree but it might be slightly out of scope, cause then it kinda becomes a marketing tool. As far as how it will be managed, the actual components I'm envisioning are two fold.
Does that make sense? |
@sftim The reasons I'm not advocating for an RSS approach is because:
My thought process is that we could open a new mailing list for Kubernetes if we needed to go the RSS/ATOM route, but I was hoping not to. |
What I'm suggesting is RSS-plus: a feed combined with a promise that you'll get a webhook when it changes. The recipient of the webhook can verify the information by fetching the RSS / ATOM / whatever, if they want to.
|
Toy implementation: run https://github.com/skx/rss2hook on CNCF infrastructure with appropriate configuration. Put the configuration in a git repo, take pull requests, link that to the app with a ConfigMap. |
@sftim This makes more sense. Thanks for this by the way! I suppose I don't understand CloudEvents well, is it possible for us to manage the effort around alerting some common forms? (PagerDuty, OpsGenie, SMS, Phone Call, Email?) I guess I'm aiming to have the CNCF/Us be responsible for alerting people to the threat in a few commonly supported formats. So I love that they can still poll the RSS endpoint and I'm on board with that, but I don't understand the next step you're talking about. (PoW or CE Payloads..) |
My concern: does CNCF want to promise alerting by SMS & phone call for cluster operators worldwide? The foundation aims to be inclusive; offering a service only in some countries might look like the opposite. Offering the service globally could be inclusive but costly - I've seen this with international phone calls as part of multifactor authentication. Offering a webhook and nothing else is a lowest common denominator: it's safe to assume that cluster operators have internet and fair to assume that they have something that can run a web server. PS. The notification payload it doesn't have to be CloudEvent, any JSON format would be fine. CloudEvent does seem like a nice standard though. |
@sftim It's sadly not necessarily safe to assume all clusters have access to the internet (I know of at least one really big cluster that is completely airgapped,) I assume the cluster operator would have access to the internet, but then we're adding additional infrastructure for them to run. As for |
I like the broad idea of this. cc @caniszczyk |
FYI GitHub now has a security advisory feature in beta you may want to take advantage of, happy to enable it for any CNCF project if you don't have it: https://help.github.com/en/articles/creating-a-maintainer-security-advisory |
This issue has been automatically marked as inactive because it has not had recent activity. |
@PushkarJ do you think that this is of relevance still today? Any comments on this from k8s security perspective? If not we will probably close due to scope. |
@lumjjb Agree with you that the scope is too wide at the moment. We are experimenting with some ideas on triage, vulnerability resolution and transparency in kubernetes sig-security. Perhaps once we have a working model and process, we could do a presentation about our approach in CNCF TAG-Security meeting and then explore how this can be adopted across all the CNCF projects (maybe as graduation criteria) ;-) So, with that said, we can close this and when the time is right, I will open a new issue and link it to this one at that time for completeness. Hope that works for all!! |
This issue has been automatically marked as inactive because it has not had recent activity. |
Closing this issue for now, linked to tracking k8s sig-security issue and will re-open when ready to present to the TAG. |
Hello there! I help lead the
sig-docs-security
working group in the Kubernetes project. We focus on surfacing and formatting security related info as well as helping to amplify the CVE management process. During our meetings a proposal has arisen to handle the CVE process in a more proactive way for our cluster operators. I asked this as a question during KubeCon EU's session on sig-security in Barcelona and was asked to open an issue here. The proposal is as follows. We would like to provide a very simple API for cluster operators to register to receive alerts based on what version of a CNCF project they are using:This API would then return (if successful validation) a unique token (which has a low collision rate and high search space):
This token can then be used to deregister the user who signed up:
Which would then deregister the user from updates if the operation was a success.
Upon a verified CVE being published, this system could be used to trigger an alert to only those affected by the specific project/version combination. This allows for 100% signal to noise ratio as far as cluster operation and CVE management are concerned.
Pros:
Cons:
Thoughts?
The text was updated successfully, but these errors were encountered: