From 0285fe315937144ec92dfac432a02035328dc6a4 Mon Sep 17 00:00:00 2001 From: Moritz Eckert Date: Wed, 27 Mar 2024 17:46:35 +0100 Subject: [PATCH] docs: add security benefits --- docs/docs/_media/personas.svg | 1 + docs/docs/_media/tcb.svg | 1 + docs/docs/basics/security-benefits.md | 140 ++++++++++++++++++++++++++ 3 files changed, 142 insertions(+) create mode 100644 docs/docs/_media/personas.svg create mode 100644 docs/docs/_media/tcb.svg diff --git a/docs/docs/_media/personas.svg b/docs/docs/_media/personas.svg new file mode 100644 index 0000000000..497036a5ae --- /dev/null +++ b/docs/docs/_media/personas.svg @@ -0,0 +1 @@ +Kubernetes clusterConfidential Micro VMConfidential Micro VMWorkload containerData ownerCoordinatorDataWorkload ownerWorkload operatorWorkload image \ No newline at end of file diff --git a/docs/docs/_media/tcb.svg b/docs/docs/_media/tcb.svg new file mode 100644 index 0000000000..ed0a8fbea7 --- /dev/null +++ b/docs/docs/_media/tcb.svg @@ -0,0 +1 @@ +Normal KubernetesKubernetesCloud & datacenterinfrastructurePhysical hostsDatacenter employeesOS, Hypervisor etc.AdminsKubernetesCloud & datacenterinfrastructurePhysical hostsControl planeWorker nodesWorkloadInfrastructure softwareEntities that could maliciously access workloadEntities that are shieldedDatacenter employeesOS, Hypervisor etc.AdminsControl planeWorker nodesWorkloadInfrastructure softwareContrast \ No newline at end of file diff --git a/docs/docs/basics/security-benefits.md b/docs/docs/basics/security-benefits.md index e69de29bb2..1bf60e3df6 100644 --- a/docs/docs/basics/security-benefits.md +++ b/docs/docs/basics/security-benefits.md @@ -0,0 +1,140 @@ +# Contrast security overview + +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. + +## Components of a Contrast deployment + +Contrast implements the [Confidential Containers](confidential-containers.md) concept. Confidential Containers significantly decrease the size of the trusted computing base (TCB) of a Kubernetes deployment, by isolating each container within its own confidential micro-VM environment. The TCB is the totality of elements in a computing environment that must be trusted not to be compromised. A smaller TCB results in a smaller attack surface. The following diagram shows how Confidential Containers remove the *cloud & datacenter infrastructure* and the *physical hosts*, including the hypervisor, the host OS, the Kubernetes control plane, and other components, from the TCB (red). Inside the confidential context (green), only the workload containers remain part of the TCB and their integrity is attested and can be [verified](../workflows/verify-cluster.md). + +![TCB comparison](../_media/tcb.svg) + +A Contrast deployment has five core components: + +* **The workload containers**: A containerized image that runs in an isolated [Confidential Container](confidential-containers.md) environment. +* **The runtime policies**: A policy that defines the runtime environment for the workload containers. Think your Kubernetes deployment YAML-file in policy format. +* **The manifest**: A manifest file defining the entire confidential deployment. It contains the policies for all containers of the deployment and the expected hardware reference values for the Confidential Container runtime environment. +* **The Coordinator**: An attestation service that runs itself in a Confidential Container in the Kubernetes cluster. The Coordinator is configured with the manifest. User-facing, you can verify this service and the effective manifest using remote attestation. Providing you with a concise attestation for the entire deployment. Cluster-facing, it verifies all containers and their policies based on remote attestation procedures and the manifest. +* **The protected data**: The data that is processed by the workload containers. + +Contrast helps protect the workload and its runtime environment's integrity and confidentiality from inspection and tampering. Furthermore, it provides the ability to attest this isolation and the workloads identity for the entire distributed application at any point in time in a single operation. + +In a Contrast deployment, there are three parties: + +* **The workload owner**, who creates a containerized image that includes an application that has access to the protected data. The workload owner doesn't have access to the data. + +* **The workload operator**, who runs the workload in a Kubernetes cluster. The operator typically has full administrative privileges to the deployment. The operator can manage cluster resources such as nodes, volumes, and networking rules, and the operator can interact with any Kubernetes or underlying cloud API. The operator doesn't have access to the workload or the data, and can't influence or modify the code or execution environment. + +* **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. + +The following diagram shows the system components and parties. + +![Components and parties](../_media/personas.svg) + +## Examples of Contrasts use cases + +Contrast helps you to isolate your workloads and data from the infrastructure and the cloud service provider. The following table describes three example use cases. + +| Use Case | Example Scenario | +|------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Migrate sensitive workloads to the cloud | TechSolve Inc., a software development firm, aimed to enhance its defense-in-depth strategy for its cloud-based development environment, especially for projects involving proprietary algorithms and client data. Contrast adds robust, multi-layered security that protects proprietary algorithms and client data against a wide range of threats, including infrastructure-based attacks and insider risks. | +| Make your SaaS more trustworthy | SaaSProviderX, a company offering cloud-based project management tools, sought to enhance its platform's trustworthiness amidst growing concerns about data breaches and privacy. Contrasts adds a new layer of verification and isolation to bolster its platform security, increased user trust, and solidified its reputation as a secure and reliable SaaS provider. | +| Simplify regulatory compliance | HealthSecure Inc. has been managing a significant volume of sensitive patient data on-premises. With the increasing demand for advanced data analytics and the need for scalable infrastructure, the firm decides to migrate its data analytics operations to the cloud. However, the primary concern is maintaining the confidentiality and security of patient data during and after the migration, in compliance with healthcare regulations. Contrasts helps leveraging confidential containers that ensure compliance and maintain data confidentiality, thereby enhancing their analytics capabilities securely. | + +In each scenario, Contrast ensures exclusive data access and processing capabilities are confined to the designated workloads. It achieves this by effectively isolating the workload from the infrastructure and other components of the stack. Data owners are granted the capability to audit and approve the deployment environment prior to submitting their data, ensuring a secure handover. Meanwhile, workload operators are equipped to manage and operate the application seamlessly, without requiring direct access to either the workload or its associated data. + +## Protecting the integrity and confidentiality of a workload + +To help protect the workload from an untrusted workload operator and the infrastructure, Contrast implements the following security controls: + +* An attestation process detects modifications to the workload image or its confidential container. This control helps protect the workload's integrity pre-attestation. +* A runtime policy and helps prevent the workload operator from accessing or compromising the instance at runtime. This control helps protect a workload's integrity and confidentiality post-attestation. + +### Attestation process + +The [attestation architecture](../architecture/attestation) describes Contrast's chain of trust and the attestation process in detail. + +## Thread model and mitigations + +This section describes the threat models that Contrast helps to mitigate. + +The following attacks are outside of the scope of this document: + +* Attacks on the application code itself, such as insufficient access controls. +* Attacks on the Confidential Computing hardware directly, such as side-channel attacks. +* Attacks on the availability, such as denial-of-service (DOS) attacks. + + +### Possible attacks + +Contrast is designed to defend against four possible attacks: + +* **A malicious cloud insider**: malicious employees or third-party contractors of cloud service providers (CSPs) has potentially full access to different layers of the cloud infrastructure. That goes from the physical datacenter up to the hypervisor and Kubernetes layer. For example, they can access the physical memory of the machines, modify the hypervisor, modify disk contents, intercept network communications, and attempt to compromise the confidential container at runtime. A malicious insider can expand the attack surface or restrict the runtime environment. For example, a malicious operator can add a storage device to introduce new attack vectors. As another example, a malicious operator can constrain resources such as limiting a guest's memory size, changing its disk space, or changing firewall rules. +* **A malicious cloud co-tenant**: malicious cloud user ("hackers") may break out of their tenancy and access other tenants' data. Advanced attackers may even be able to establish a permanent foothold within the infrastructure and access data over a longer period. The threats are analogously to the *cloud insider access* scenario, without the physical access. +* **A malicious workload operator**: malicious workload operators, for example Kubernetes administrators, have full access to the workload deployment and the underlying Kubernets platform. The threats are analogously to the *cloud insider access* scenario, with access to everything that is above the hypervisor level. +* **A malicious attestation client**: this attacker connects to the attestation service and sends malformed request. +* **A malicious workload owner**: a malicious workload owner has full control over the application development itself. This attacker might release a malicious version of the workload containing harmful operations. + +### Attack surfaces + +The following table describes the attack surfaces that are available to attackers. + +| Attacker | Target | Attack surface | Risks | +|------------------------------------------------|----------------------------------|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| +| Cloud insider | Confidential Container, Workload | Physical memory | Attacker can dump the physical memory of the workloads. | +| Cloud insider, cloud hacker, workload operator | Confidential Container, Workload | Disk reads | Anything read from the disk is within the attacker's control. | +| Cloud insider, cloud hacker, workload operator | Confidential Container, Workload | Disk writes | Anything written to disk is visible to an attacker. | +| Cloud insider, cloud hacker, workload operator | Confidential Container, Workload | Kubernetes Control Plane | Instance attributes read from the Kubernetes control plane, including mount points and environment variables, are within the attacker's control. | +| Cloud insider, cloud hacker, workload operator | Confidential Container, Workload | Container Runtime | The attacker can use container runtime APIs (e.g. "kubectl exec") to perform operations on the workload container. | +| Cloud insider, cloud hacker, workload operator | Confidential Container, Workload | Network | Intra deployment (between containers) as well as external network connections to the image repository or attestation service can be intercepted. | +| Attestation client | Coordinator attestation service | Attestation requests | The attestation service has complex, crypto-heavy logic that is challenging to write defensively. | +| Workload owner | Workload | Workload | This attacker might release an upgrade to the workload containing harmful changes, such as a backdoor. | | + +### Threats and mitigations + +The container root file system with [integrity protection](../architecture/confidential-containers.md) is designed to mitigate risks from disk attacks. +Secrets are never disclosed in plaintext form to the disk or to any external device. + +Risks from network attacks are mitigated by having [authenticated, end-to-end encrypted channels](../architecture/network-encryption/). +An [attestation protocol](../architecture/attestation) helps protect the boot sequence. +[Runtime policies](../architecture/attestation/runtime-policies.md) verify the runtime environment configuration read from the Kubernetes control plane. + +The following tables describe the threats and mitigations: + +* Attacks on the confidential container environment +* Attacks on the attestation service +* Attacks on workloads + + +#### Attacks on the confidential container environment + +This table describes potential threats and mitigation strategies related to the confidential container environment. + +| Threat | Mitigation | Mitigation implementation | +|----------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| +| An attacker intercepts the network connection of the launcher or image repository. | An attacker can change the image URL and control the workload binary. However these actions are reflected in the attestation report. The image repository is not controlled using an access list, therefore the image is assumed to be viewable by everyone. You must ensure that the workload container image doesn't contain any secrets. | Within the Contrast container image | +| An attacker modifies the workload image on disk after it was downloaded and measured. | This threat is mitigated by a read-only partition that is integrity-protected. The workload image is protected by dm-verity. | Within the Contrast container image | +| An attacker modifies the environment configuration in the Kubernetes control plane, and controls the image repository URL. | The attestation process and the runtime policies detects unsafe configurations that load non-authentic images or perform any other modification to the expected runtime. environment. | Within the runtime policies | + +#### Attacks on the Coordinator attestation service + +This table describes potential threats and mitigation strategies to the attestation service. + +| Threat | Mitigation | Mitigation implementation | +|-----------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------| +| An attacker intercepts the Coordinator deployment and modifies the image or hijacks the runtime environment. | This threat is mitigated by having an attestation procedure and attested, encrypted TLS connections to the Coordinator. The attestation evidence for the Coordinator image is distributed with our releases and protected by supply chain security. | Within the CLI and the Coordinator | +| An attacker intercepts the network connection between the workload and the Coordinator and reads secret keys from the wire. | This threat is mitigated by having an attested, encrypted TLS connection. This connection helps protect the token from passive eavesdropping. An attacker cannot impersonate the Coordinator because they are missing the Coordinator's private key. The attacker cannot create valid workload certificates that would be accepted in Contrast's service mesh. An attacker cannot impersonate a valid workload container because the container's identity is guaranteed by the attestation protocol. | Within the network between your workload and the Coordinator. | +| An attacker exploits parsing discrepancies, which leads to undetected changes in the attestation process. | This risk is mitigated by having a parsing engine written in memory-safe Go that is tested against the attestation specification of the hardware vendor. The runtime policies are available as an attestation artifact for further inspection and audits to verify their effectivness. | Within the Coordinator | +| An attacker uses all service resources, which brings the Coordinator down in a denial of service (DoS) attack. | This reliability risk is mitigated by having a distributed, Coordinator service that can be easily replicated and scaled out as needed. | Within the Coordinator | +#### Attacks on workloads + +This table describes potential threats and mitigation strategies related to workloads. + +| Threat | Mitigation | Mitigation implementation | +|--------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| +| An attacker intercepts the network connection between two workload containers. | This threat is mitigated by having transparently encrypted TLS connections between the containers in your deployment. | Within the Contrast container image | +| An attacker reads or modifies data written to disk via persistent volumes. | Currently persistent volumes are not supported in Contrast. In the future, this threat is mitigated by encrypted and integrity-protected volume mounts. | Within the Contrast container image | +| An attacker publishes a new image version containing malicious code. | The attestation process and the runtime policies require a data owner to accept a specific version of the workload and any update to the workload needs to be explicitly acknowledged. | Within the attestation procedure |