docs: add security benefits #283
Conversation
|
@m1ghtym0 could you fix the broken link so the preview renderes? |
|
|
|
||
| This document outlines the security measures of Contrast and its capability to counter various threats effectively. Contrast is designed to shield entire Kubernetes deployments from the infrastructure, enabling entities to manage sensitive information (such as regulated or personally identifiable information (PII)) in the public cloud, while maintaining data confidentiality and ownership. It ensures data isolation, making it accessible solely to the workload and the data's initial owners. | ||
|
|
||
| Contrast is applicable in situations where establishing trust with the workload manager or the underlying infrastructure is challenging. This is particularly beneficial for regulated sectors looking to transition sensitive activities to the cloud, without sacrificing security or compliance. It allows for cloud adoption by maintaining a separation from the cloud service provider in terms of trust. |
There was a problem hiding this comment.
| Contrast is applicable in situations where establishing trust with the workload manager or the underlying infrastructure is challenging. This is particularly beneficial for regulated sectors looking to transition sensitive activities to the cloud, without sacrificing security or compliance. It allows for cloud adoption by maintaining a separation from the cloud service provider in terms of trust. | |
| Contrast is applicable in situations where establishing trust with the workload operator or the underlying infrastructure is challenging. This is particularly beneficial for regulated sectors looking to transition sensitive activities to the cloud, without sacrificing security or compliance. It allows for cloud adoption by maintaining a separation from the cloud service provider in terms of trust. |
There was a problem hiding this comment.
where establishing trust with the workload manager or the underlying infrastructure is challenging
In general, we don't shield against the infrastructure but the infrastructure operator. Parts of the infrastructure (CPU) are explicitly trusted.
|
|
||
| * **The data owners**, who own the protected data. A data owner can verify the deployment using the Coordinator attestatioin service. The verification includes the identity, integrity, and confidentiality of the workloads, the runtime environment and the access permissions. The data owners don't have access to the workload. | ||
|
|
||
| Contrast supports a trust model where the workload owner, workload operator, and data owners are separate, mutually distrusting parties. |
There was a problem hiding this comment.
I don't think we are there yet regarding workload owner and data owner - at least not without handing over all relevant infra yaml to the data owner. See also https://cloud-native.slack.com/archives/C05HD8JDY79/p1707255871825719
There was a problem hiding this comment.
Which part of the commented section states that handing over infra YAML isn't needed?
There was a problem hiding this comment.
Fair point. However, I think we'll need to decide at some point which trust model we want to support (could be both mutual-distrust and some-trust) and document the corresponding requirements and trade-offs. We might want to add a reminder for ourselves to https://github.com/edgelesssys/contrast/blob/main/README.md#verify-the-coordinator.
There was a problem hiding this comment.
Yes, but isn't this mainly a use-case perspective? We want to support the mutual-distrust model, which implicitly supports weaker models?
I agree we need to document in detail how the mutual-distrust model can be achieved.
m1ghtym0
force-pushed
the
m/threat-model
branch
from
9c4b312 to
a0b92b5
Compare
docs/docs/_media/personas.svg
Outdated
There was a problem hiding this comment.
I don't know what best practices for illustrations are, but to avoid confusion e.g. if "operator" is the K8s operator or a persona, maybe we should switch the icons to persons and put the current icon next to the arrow (for data owner and container image provider) and just to the K8s logo for the workload operator?
Not sure if it makes things more complicated though because of the amounts of icon..
Co-authored-by: Paul Meyer <[email protected]> Co-authored-by: Markus Rudy <[email protected]>
Co-authored-by: 3u13r <[email protected]>
m1ghtym0
force-pushed
the
m/threat-model
branch
from
6a047c0 to
234d9ed
Compare
Please let me know what you think and give feedback: