apply suggestions

docs/docs/basics/security-benefits.md

@@ -1,34 +1,47 @@
 # 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.
+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.
 
-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.
+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.
 
 ## 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](../architecture/attestation/hardware.md).
+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).
+In the confidential context, represented by green, only the workload containers along with their confidential micro-VM environment are included within the Trusted Computing Base (TCB).
+Their integrity is attested and can be [verified](../architecture/attestation/hardware.md)
+
+Confidential Containers fundamentally utilize [hardware-based mechanisms](../basics/confidential-containers.md), specifically leveraging CPU features, to ensure the isolation of the confidential context.
+This implies that both the CPU and its microcode are integral components of the TCB.
+However, it should be noted that the hardware aspects are not depicted in the accompanying graphic.
 
 ![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 workload containers**: A container 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.
 * **The manifest**: A manifest file defining the reference values of an entire confidential deployment. It contains the policy hashes for all pods 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 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 pods 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.
+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 container image provider**, who creates a container image that includes an application that has access to the protected 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 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 data owners**, who own the protected data. A data owner can verify the deployment using the Coordinator attestation 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.
+* **The data owners**, who own the protected data. A data owner can verify the deployment using the Coordinator attestation service. The verification includes the identity, integrity, and confidentiality of the workloads, the runtime environment and the access permissions.
 
-Contrast supports a trust model where the workload owner, workload operator, and data owners are separate, mutually distrusting parties.
+Contrast supports a trust model where the container image provider, workload operator, and data owners are separate, mutually distrusting parties.
 
 The following diagram shows the system components and parties.
 
@@ -76,7 +89,7 @@ Contrast is designed to defend against five possible attacks:
 * **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 analogous 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.
+* **A malicious container image provider**: a malicious container image provider has full control over the application development itself. This attacker might release a malicious version of the workload containing harmful operations.
 
 ### Attack surfaces
 
@@ -91,7 +104,7 @@ The following table describes the attack surfaces that are available to attacker
 | 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.                                                               |                                                             |
+| container image provider                                 | Workload                         | Workload                 | This attacker might release an upgrade to the workload containing harmful changes, such as a backdoor.                                                               |                                                             |
 
 ### Threats and mitigations