Publish threat model in documentation #6263
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: evankanderson 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 |
knative-prow
bot
added
the
approved
knative-prow
bot
added
the
size/L
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| * [Threat model](https://github.com/knative/community/blob/main/working-groups/security/threat-model.md) | ||
|
|
||
| ## Code Signature Verification |
There was a problem hiding this comment.
I moved this to verifying-cli.md, as it didn't really fit with the rest of the overview
|
bump @davidhadas |
| ... | ||
| TeamIdentifier=7R64489VHL | ||
| ``` | ||
|
|
||
| ## Report a vulnerability |
There was a problem hiding this comment.
I believe we were planning to move from mailing report to github for reporting a security vulnerability. This ode snot have to be done in this PR, but I thought to bring this up in case we chose to also do it here.
There was a problem hiding this comment.
I was going to do that as a follow-on, as we haven't set up private vulnerability reporting consistently on all the repos yet.
| @@ -0,0 +1,373 @@ | |||
| # Knative Threat Model | |||
|
|
|||
| This document describes the Knative threat model. When vulnerabilities are | |||
There was a problem hiding this comment.
This first paragraph try to answer the question when do we use the Knative threat model rather than describing what it is or giving any useful information for it. I think it a side note how we may use it and not a good way to start the document.
There was a problem hiding this comment.
I moved this paragraph to a "Usage of this document" coda.
| supply chain security threats (which it largely inherits from | ||
| [CNCF Buildpacks](https://buildpacks.io/)). | ||
|
|
||
| Knative builds on the capabilities of the Kubernetes cluster, and exposes both |
There was a problem hiding this comment.
This second paragraph seem to frame the Knative threat model and its relationship with best practices - again I do not think it is a helpful starting statement for a page spelling out what is the Knative threat model - the information should be in the doc, but we first need to layout what is the Knative threat model...
| example, Knative Serving routes and Kubernetes NetworkPolicy) will be called | ||
| out. | ||
|
|
||
| Knative aims to support application teams from a single organization working in |
There was a problem hiding this comment.
This third paragraph does provide some information about what the threat model is. I do think we need to find a way to make it more comprehensive and say what it is and not what it is not (i.e. not talk about multiple clusters in here , multiple clusters can be discussed at a later limitations section maybe). Maybe start by stating that Knative is an extension to the Kubernetes control plan that automates certain Kubernetes control mechanisms, offering a more abstracted service to users. Give some more information about what is a Knative service and what it encompass. Stating the association between users and namespaces, the association between resources and namespaces and between Knative serivces and namespaces.
Than, we can move to make some initial statmenet on the security model, e.g. that the security threat model includes attacks by malicious knative users, or by other Kubernetes users or by other unauthorized users on the Knative control plan, or on resources/services/namespaces that are not designated to them and.... (see what else we should say on this initial description of the threat model). Once we put all that in writing we can draw the line to say that the Knative Threat Model does not include.... attacks on the underlying Kubernetes system unless they are faciliated by Knative presence and our assumptions about the Kubernets following best practices. In this context we should say that it is Knative responsibility to ensure K~native services follow best practices by default but Knatiev may support user configurations which do not support best practices as long as user actively set them as such.... etc.
There was a problem hiding this comment.
Thanks for the feedback! I've moved this to the first paragraph, to define the goals of the project. As this threat model aims to cover both serving and eventing, I'm not sure that defining what a Knative Service is (and not what Brokers, Triggers, Sources, etc are) makes sense here, rather than by linking to the existing component descriptions.
I added a sentence here to clarify what the namespace-as-a-service tenancy model means:
Each team (users in a namespace) should be isolated from affecting the
configuration, availability, or integrity of applications in other namespaces.
Check in a format threat model, following up on the commitment in cncf/toc#1509 (comment) (Better late than never!)
Proposed Changes
communityrepo with the AdaLogics report, and adds a bunch of new content that I've been meaning to write. It does not currently include diagrams, though I may add some later.Once this is merged, I intend to redirect the draft threat model from the
communityrepo to this documentation.