search

confidential-containers / documentation

Documentation for the confidential containers project
Apache License 2.0
73 stars 48 forks source link

Add Draft High Level Trust/Threat Model #14

Closed magowan closed 2 years ago

magowan commented 2 years ago

Produce a draft capturing Personas, Components and Artifacts for discussion. This will form basis of describing/modelling specific threats.

Updated with individual PR links

Orig PR -> https://github.com/confidential-containers/documentation/pull/16 (Don't use now replaced by individual PRS above)

jiazhang0 commented 2 years ago

Here is the initial draft for comments: https://github.com/jiazhang0/documentation/blob/main/Threat-and-trust-model.md

magowan commented 2 years ago

here are my thoughts so far -> https://github.com/magowan/documentation/tree/TrustModel Two files essentially TrustModel and ThreatModel. The ThreatModel is just a few examples to start to show how we can use what is in the TrustModel to define Threats. The Trust Model starts to try and establish what we need to talk about in our threats. I think we should create several PR's, one for high level personas, artifacts and components so we can get agreement on that. Then we split up the Threats we model in some way so we can have reasonably size PR's. How we group threats together though and quite how to structure them I haven;t a strong view on yet

I'll take a look at your fork and we can figure out how to merge our thinking.

magowan commented 2 years ago

I am keen to bring terminology etc closer to a cloud native sort of architecture, and move away from more generic host/guest to be more specific node/pod/container for example. I think what we have both written can actually fit together i think it just comes down to how we structure the information.

I have perhaps gone in preparing for the detailed level to come but your text helps expand at a higher level the areas of concern a bit more detail no technology.

I am keen to draw out personas as you mention "the platform owner, operator and attacker" as these will directly impact upon some of the threats we seek to address and I can see that perhaps kubernetes admin is operatorm infrastructure admin is platform owner in the language I use.

I am not so sure about the columns vm-cc, microvm-cc/kata-cc*1, enclave-cc as I feel this is quite removed from cloud terms? I guess I think of this as node, pod, container but that isn;t quite a match either.... I'll keep thinking.. ...

jiazhang0 commented 2 years ago

@magowan I like your idea about the personas. Your personas shows 4 subject roles, which corresponds to 4 objects used in cloud native security: https://kubernetes.io/docs/concepts/security/overview/

I try to search the hints about the personas related to cloud native for references:

The purpose of using the terms "vm-cc", "microvm-cc/kata-cc", "enclave-cc" is to try to address various approaches of technical implementations of confidential container and theirs trust boundaries. So Node, Pod, Container/Process would make sense to you.

magowan commented 2 years ago

I am splitting out the big PR https://github.com/confidential-containers/documentation/pull/16 into smaller focused Pull Requests. I will look to address comments from this large Pull Request in the appropriate smaller pull requests as they appear.

First one is ready for full review and covers the introduction and pulling in of reference material and can be found here -> https://github.com/confidential-containers/documentation/pull/22

Next one will cover the Personas.

magowan commented 2 years ago

Closed and now covered under confidential-containers/confidential-containers#117