[WIP] Security process(es) doc

[dims]

Which issue(s) this PR fixes:

Fixes #

[dims]

cc @PushkarJ

[raesene]

This bit will open up a question of "which documented secure defaults we mean", as distros often have different ideas of secure defaults. I can initially think of a couple of options here

• Pick a set of defaults to reference (e.g. Kubeadm defaults) I would lean against saying "Kubernetes component defaults" here as some of those are not what people run in production clusters.
• Exclude anything that can be configured (i.e. there is an option of secure configuration available) from Kubernetes CVEs. so that way a valid report might be "this is insecure and there's no configuration option to make it secure" but "hey out of the box this is insecure" would not be.

Honestly that last one might make more sense. Realistically out of the box, Kubernetes is not a secure enterprise platform, it needs external software and/or additional configuration (e.g. no default netpol, anyone who can create pods gets root on any node)

[dims]

Would like some SRC input on this for sure :)

[raesene]

Do we want an exclusion for "things we already know about" here, to avoid people re-discovering old issues and thinking they're a new finding. For this sources like the results of 3rd party audit would be a good starting point, also there's also things like open GH issues (e.g. 18982) and some things like https://kinvolk.io/blog/2019/02/abusing-kubernetes-apiserver-proxying which don't even have a GH issue.

Ideally I guess it'd be nice to have a list of all of those in one place, but that's not something that exists at the moment(AFAIK)

[dims]

Can you please suggest some language i can incorporate @raesene ? thanks!

[PushkarJ]

@dims Thank you for compiling this. Overall I like the intent of the document and most of the content. Left several suggestions and asked some clarifying questions.

[PushkarJ]

Thanks for putting this together. This doc compiles / summarizes text spread out across several different places with appropriate links. I urge all my fellow maintainers to use this as guidance to decide what is worth their time when it comes to vulnerability related requests as well as use it as a shield when urgent fixes are requested with no regard for precious maintainer time.

Optionally: It would be great to get a review from @kubernetes/security-response-committee and @kubernetes/sig-contributor-experience to ensure nothing is accidentally missed or mis-represented.

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dims, PushkarJ
Once this PR has been reviewed and has the lgtm label, please assign mrbobbytables for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• contributors/guide/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aojea]

does it matter the origin, if is not reproducible it does not really matter if is AI generated or manually ?

I think that this is a more call of warning that "AI automated report must be curated and validated by the reporter"

[aojea]

does this really mean "out-of-tree Kubernetes SIG projects"? or not kubernetes/kubernetes and SIG projects? because all kubernetes sig projects are out of tree, unless we consider the ones that we revendor in kubernetes/kubernetes 🤔

[aojea]

+1 some non-binding feedback.
I think the document can be simplified , it looks to me that some content is duplicated and some areas require a lot of kubernetes community knowledge, if the audience is for new or not core contributors unfamiliar with the release process or non-contributors there are parts that may not understand, a intro with the description of core, non-core sigs and explaining those are github repositories may help? then just reference those definitions?
+1 on the message of "don't spam us with AI automated generated reports" that is expressed in several places but I wonder if we can just aggregate all those calls in a Warning Note in a visible part of the doc.

[raesene]

Suggested change

	- **Issues relating to known Kubernetes project architectural choices and accepted risks. Anything that's already been noted in a existing security audit or public blog which the project has chosen not to fix by issuing a patch.

The comment's dropped off the review list but this was some possible wording addressing the idea that we won't issue CVEs for things we already know about. The idea here is to avoid submissions (especially AI gen ones) that are just based on existing known issues (e.g. the unclosed ones from third party audits, the unpatchable CVEs or things like the kinvolk pod proxy attack)