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.
There was a problem hiding this comment.
I made some changes to make it more specific to Knative, to start highlighting the threat model of Knative - beyond the one of K8s.
The main theme of this doc in my view is:
We extend the K8s control plan.
We have these actors and components (teams in namespaces etc., components in the control plans...).
Our control plan has Admin privileges and serves all teams
Threats:
- There are threats that teams will attack the control plan.
- There are threats that teams will attack each other
- There are threats that others on the same cluster will attack the control plan.
- There are threats that others on the same cluster will attack one of the teams (or its application)
- There are threats that third party will attack the control plan
- There are threats that third party will attack one of the teams (or its application)
I think these are the 6 main bundles of threats to point out and analyze in some high level suitable for this doc.
| @@ -0,0 +1,378 @@ | |||
| # Knative Threat Model | |||
|
|
|||
| Knative aims to support application teams from a single organization working in | |||
There was a problem hiding this comment.
| Knative aims to support application teams from a single organization working in | |
| Knative extends the Kubernetes control plan offering a more abstracted service to users. As such, the Knative threat model require protecting Knative specific control services as well as the underlying Kubernetes infrastructure. | |
| Knative aims to support application teams from a single organization working in |
| [Namespace-as-a-Service multi-tenancy model](https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/), | ||
| as well as the Cluster-as-a-Service model. The Namespace-as-a-Service model | ||
| means that multiple teams (tenants) may each be operating Knative custom | ||
| resources within a common cluster, sharing control plane and node resources. |
There was a problem hiding this comment.
| resources within a common cluster, sharing control plane and node resources. | |
| resources within a common cluster, sharing both the Knative control plane, the underlying Kubernetes control plan and node resources. |
| as well as the Cluster-as-a-Service model. The Namespace-as-a-Service model | ||
| means that multiple teams (tenants) may each be operating Knative custom | ||
| resources within a common cluster, sharing control plane and node resources. | ||
| Each team (users in a namespace) should be isolated from affecting the |
There was a problem hiding this comment.
| Each team (users in a namespace) should be isolated from affecting the | |
| Each team (users in a namespace) should be isolated and protected from intentional or unintentional misconduct by other teams using a different namespace; and by other users running in the same Kubernetes cluster; and by any third party. Knative users and any other user running on the same cluster should not be able to affect the Knative control plane, its |
| means that multiple teams (tenants) may each be operating Knative custom | ||
| resources within a common cluster, sharing control plane and node resources. | ||
| Each team (users in a namespace) should be isolated from affecting the | ||
| configuration, availability, or integrity of applications in other namespaces. |
There was a problem hiding this comment.
| configuration, availability, or integrity of applications in other namespaces. | |
| configuration, availability. They should also not be able to obtain private information of any of the Knative services other than their own, or affect the 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.