diff --git a/docs/docs/overview/confidential-kubernetes.md b/docs/docs/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/docs/overview/confidential-kubernetes.md +++ b/docs/docs/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.0/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.0/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.0/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.0/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.1/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.1/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.1/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.1/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.10/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.10/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.10/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.10/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.11/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.11/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.11/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.11/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.12/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.12/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.12/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.12/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.13/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.13/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.13/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.13/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.14/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.14/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.14/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.14/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.15/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.15/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.15/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.15/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.16/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.16/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.16/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.16/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.17/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.17/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.17/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.17/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.18/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.18/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.18/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.18/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.19/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.19/overview/confidential-kubernetes.md index ca20df4de7..bff8c33229 100644 --- a/docs/versioned_docs/version-2.19/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.19/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.2/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.2/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.2/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.2/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.3/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.3/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.3/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.3/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.4/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.4/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.4/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.4/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.5/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.5/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.5/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.5/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.6/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.6/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.6/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.6/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.7/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.7/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.7/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.7/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.8/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.8/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.8/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.8/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg) diff --git a/docs/versioned_docs/version-2.9/overview/confidential-kubernetes.md b/docs/versioned_docs/version-2.9/overview/confidential-kubernetes.md index 2b6c6ed17d..1441c833a1 100644 --- a/docs/versioned_docs/version-2.9/overview/confidential-kubernetes.md +++ b/docs/versioned_docs/version-2.9/overview/confidential-kubernetes.md @@ -23,9 +23,9 @@ With the above, Constellation wraps an entire cluster into one coherent and veri ![Confidential Kubernetes](../_media/concept-constellation.svg) -## Contrast: Managed Kubernetes with CVMs +## Comparison: Managed Kubernetes with CVMs -In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. +In comparison, managed Kubernetes with CVMs, as it's for example offered in [AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/) and [GKE](https://cloud.google.com/kubernetes-engine), only provides runtime encryption for certain worker nodes. Here, each worker node is a separate (and typically unverified) confidential context. This only provides limited security benefits as it only prevents direct access to a worker node's memory. The large majority of potential attacks through the infrastructure remain unaffected. This includes attacks through the control plane, access to external key management, and the corruption of worker node images. This leaves many problems unsolved. For instance, *Node A* has no means to verify if *Node B* is "good" and if it's OK to share data with it. Consequently, this approach leaves a large attack surface, as is depicted in the following. ![Concept: Managed Kubernetes plus CVMs](../_media/concept-managed.svg)