mirror of
https://github.com/edgelesssys/constellation.git
synced 2024-10-01 01:36:09 -04:00
docs: minor wording fixes in overview pages
This commit is contained in:
Thomas Tendyck
Thomas Tendyck
parent
6401c345f0
commit
a283f96b87
@ -11,7 +11,7 @@ Welcome to the documentation of Constellation! Constellation is a Kubernetes eng
|
||||
Constellation shields your entire Kubernetes cluster from the underlying cloud infrastructure. Everything inside is always encrypted, including at runtime in memory. For this, Constellation leverages a technology called *confidential computing* and more specifically Confidential VMs.
|
||||
|
||||
:::tip
|
||||
See our 📄[whitepaper](https://content.edgeless.systems/hubfs/Confidential%20Computing%20Whitepaper.pdf) for more information on confidential computing.
|
||||
See the 📄[whitepaper](https://content.edgeless.systems/hubfs/Confidential%20Computing%20Whitepaper.pdf) for more information on confidential computing.
|
||||
:::
|
||||
|
||||
## Goals
|
||||
@ -31,4 +31,4 @@ Constellation provides unique security [features](overview/confidential-kubernet
|
||||
|
||||
## Next steps
|
||||
|
||||
You can learn more about the concept of Confidential Kubernetes, features, security benefits, and performance of Constellation in the *Basics* section. To jump right into the action head to *Getting Started*.
|
||||
You can learn more about the concept of Confidential Kubernetes, features, security benefits, and performance of Constellation in the *Basics* section. To jump right into the action head to *Getting started*.
|
||||
|
||||
@ -16,9 +16,9 @@ The following table summarizes the state of features for different infrastructur
|
||||
| **Feature** | **Azure** | **GCP** | **AWS** | **OpenStack (Yoga)** |
|
||||
|-------------------------------|-----------|---------|---------|----------------------|
|
||||
| **1. Custom images** | Yes | Yes | No | Yes |
|
||||
| **2. SEV-SNP or TDX** | Yes | No | No | Depends on Kernel/HV |
|
||||
| **3. Raw guest attestation** | Yes | No | No | Depends on Kernel/HV |
|
||||
| **4. Reviewable firmware** | No* | No | No | Depends on Kernel/HV |
|
||||
| **2. SEV-SNP or TDX** | Yes | No | No | Depends on kernel/HV |
|
||||
| **3. Raw guest attestation** | Yes | No | No | Depends on kernel/HV |
|
||||
| **4. Reviewable firmware** | No* | No | No | Depends on kernel/HV |
|
||||
|
||||
## Microsoft Azure
|
||||
|
||||
@ -36,8 +36,8 @@ AWS currently doesn't offer CVMs. AWS proprietary Nitro Enclaves offer some rela
|
||||
|
||||
## OpenStack
|
||||
|
||||
OpenStack is an open-source cloud and infrastructure management software. It's used by many smaller CSPs and datacenters. In the latest *Yoga* version, OpenStack has basic support for CVMs. However, much depends on the employed Kernel and hypervisor. Features (2)--(4) are likely to be a *Yes* with Linux Kernel version 6.2. Thus, going forward, OpenStack on corresponding AMD or Intel hardware will be a viable underpinning for Constellation.
|
||||
OpenStack is an open-source cloud and infrastructure management software. It's used by many smaller CSPs and datacenters. In the latest *Yoga* version, OpenStack has basic support for CVMs. However, much depends on the employed kernel and hypervisor. Features (2)--(4) are likely to be a *Yes* with Linux kernel version 6.2. Thus, going forward, OpenStack on corresponding AMD or Intel hardware will be a viable underpinning for Constellation.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The different clouds and software like the Linux Kernel and OpenStack are in the process of building out their support for state-of-the-art CVMs. Azure has already most features in place. For Constellation, the status quo means that the TCB has different shapes on different infrastructures. With broad SEV-SNP support coming to the Linux Kernel, we soon expect a normalization of features across infrastructures.
|
||||
The different clouds and software like the Linux kernel and OpenStack are in the process of building out their support for state-of-the-art CVMs. Azure has already most features in place. For Constellation, the status quo means that the TCB has different shapes on different infrastructures. With broad SEV-SNP support coming to the Linux kernel, we soon expect a normalization of features across infrastructures.
|
||||
|
||||
@ -15,8 +15,8 @@ Constellation implements the Confidential Kubernetes concept with the following
|
||||
* **Runtime encryption**: Constellation runs all Kubernetes nodes inside Confidential VMs (CVMs). This gives runtime encryption for the entire cluster.
|
||||
* **Network and storage encryption**: Constellation augments this with transparent encryption of the [network](../architecture/networking.md) and [persistent storage](../architecture/encrypted-storage.md). Thus, workloads and control plane are truly end-to-end encrypted: at rest, in transit, and at runtime.
|
||||
* **Transparent key management**: Constellation manages the corresponding [cryptographic keys](../architecture/keys.md) inside CVMs.
|
||||
* **Node attestation & verification**: Constellation verifies the integrity of each new CVM-based node using [remote attestation](../architecture/attestation.md). Only "good" nodes receive the cryptographic keys required to access the network and storage of a cluster.
|
||||
* **Confidential computing-optimized images**: A node is "good" if it's running a signed Constellation [node image](../architecture/networking.md) inside a CVM and is in the expected state. (Node images are hardware-measured during boot and are reflected. The measurements are reflected in the attestation statements that are produced by nodes and verified by Constellation.)
|
||||
* **Node attestation and verification**: Constellation verifies the integrity of each new CVM-based node using [remote attestation](../architecture/attestation.md). Only "good" nodes receive the cryptographic keys required to access the network and storage of a cluster.
|
||||
* **Confidential computing-optimized images**: A node is "good" if it's running a signed Constellation [node image](../architecture/images.md) inside a CVM and is in the expected state. (Node images are hardware-measured during boot. The measurements are reflected in the attestation statements that are produced by nodes and verified by Constellation.)
|
||||
* **"Whole cluster" attestation**: Towards the DevOps engineer, Constellation provides a single hardware-rooted certificate from which all of the above can be verified.
|
||||
|
||||
With the above, Constellation wraps an entire cluster into one coherent and verifiable *confidential context*. The concept is depicted in the following.
|
||||
@ -29,7 +29,7 @@ In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](
|
||||
|
||||
|
||||
|
||||
The following table highlights the key differences in terms of features:
|
||||
The following table highlights the key differences in terms of features.
|
||||
|
||||
| | Managed Kubernetes with CVMs | Confidential Kubernetes (Constellation✨) |
|
||||
|-------------------------------------|------------------------------|--------------------------------------------|
|
||||
|
||||
@ -20,6 +20,6 @@ These terms may be different for future releases.
|
||||
|
||||
### Enterprise License
|
||||
|
||||
Enterprise Licenses don't have the above limitations and come with support and additional features. Find out more [here](https://www.edgeless.systems/products/constellation/).
|
||||
Enterprise Licenses don't have the above limitations and come with support and additional features. Find out more at the [product website](https://www.edgeless.systems/products/constellation/).
|
||||
|
||||
Once you have received your Enterprise License file, place it in your [Constellation workspace](../architecture/orchestration.md#workspaces) in a file named `constellation.license`.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Performance
|
||||
|
||||
This section analyses the performance of Constellation.
|
||||
This section analyzes the performance of Constellation.
|
||||
|
||||
## Performance impact from runtime encryption
|
||||
|
||||
@ -48,7 +48,7 @@ Using the default [K-Bench test configurations](https://github.com/vmware-tanzu/
|
||||
#### Kubernetes API Latency
|
||||
|
||||
At its core, the Kubernetes API is the way to query and modify a cluster's state. Latency matters here. Hence, it's vital that even with the additional level of security from Constellation's network the API latency doesn't spike.
|
||||
K-Bench's `default` test performs calls to the API to create, update and delete cluster resources.
|
||||
K-Bench's `default` test performs calls to the API to create, update, and delete cluster resources.
|
||||
|
||||
The three graphs below compare the API latencies (lower is better) in milliseconds for pods, services, and deployments.
|
||||
|
||||
@ -66,8 +66,8 @@ Deployments: Constellation has the lowest latency for all cases except for scali
|
||||
|
||||
#### Network
|
||||
|
||||
When it comes to network performance, there are two main indicators we need to differentiate: intra-node and inter-node transmission speed.
|
||||
K-Bench provides benchmark tests for both, configured as `dp_netperf_internode`, `dp_network_internode`, `dp_network_intranode`.
|
||||
There are two main indicators for network performance: intra-node and inter-node transmission speed.
|
||||
K-Bench provides benchmark tests for both, configured as `dp_netperf_internode`, `dp_network_internode`, and `dp_network_intranode`.
|
||||
|
||||
##### Inter-node
|
||||
|
||||
@ -83,7 +83,7 @@ The connections directly pass through the node's OS layer and never hit the netw
|
||||
The benchmark evaluates how the [Constellation's node OS image](../architecture/images.md) and runtime encryption influence the throughput.
|
||||
|
||||
The K-Bench tests `dp_network_internode` and `dp_network_intranode`. The tests use [`iperf`](https://iperf.fr/) to measure the bandwidth available.
|
||||
Constellation's bandwidth for both sending and receiving is at 20 Gbps while AKS achieves slightly higher numbers and GKE achieves about 30 Gbps in our tests.
|
||||
Constellation's bandwidth for both sending and receiving is at 20 Gbps while AKS achieves slightly higher numbers and GKE achieves about 30 Gbps in the tests.
|
||||
|
||||
|
||||
|
||||
@ -97,11 +97,11 @@ Similarly, Constellation will provision a PV via a default storage class upon a
|
||||
The K-Bench [`fio`](https://fio.readthedocs.io/en/latest/fio_doc.html) benchmark consists of several tests.
|
||||
We selected four different tests that perform asynchronous access patterns because we believe they most accurately depict real-world I/O access for most applications.
|
||||
|
||||
In the graph below, you will find the I/O throughput in MiB/s - where higher is better.
|
||||
The following graph shows I/O throughput in MiB/s (higher is better).
|
||||
|
||||
|
||||
|
||||
Comparing Constellation on GCP with GKE, we see that Constellation offers similar read/write speeds in all scenarios.
|
||||
Comparing Constellation on GCP with GKE, you see that Constellation offers similar read/write speeds in all scenarios.
|
||||
|
||||
Constellation on Azure and AKS, however, partially differ. Only for the full write mix, Constellation and AKS have similar storage access speeds. In the `70/30 mix`, AKS outperforms Constellation.
|
||||
|
||||
|
||||
@ -7,5 +7,5 @@ From a security perspective, Constellation implements the [Confidential Kubernet
|
||||
From an operational perspective, Constellation provides the following key features:
|
||||
|
||||
* **Native support for different clouds**: Constellation works on Microsoft Azure and Google Cloud Platform (GCP). Support for Amazon Web Services (AWS) and OpenStack-based environments is coming with a future release. Constellation securely interfaces with the cloud infrastructure to provide [cluster autoscaling](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), [dynamic persistent volumes](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/), and [service load balancing](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
|
||||
* **Highly availability**: Constellation combines a [multi-master architecture](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) with a [stacked etcd topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) to ensure high availability.
|
||||
* **High availability**: Constellation uses a [multi-master architecture](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) with a [stacked etcd topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) to ensure high availability.
|
||||
* **Integrated Day-2 operations**: Constellation lets you securely [upgrade](../workflows/upgrade.md) your cluster to a new release. It also lets you securely [recover](../workflows/recovery.md) a failed cluster. Both with a single command.
|
||||
|
||||
@ -13,10 +13,10 @@ This opens up a large attack surface where workloads and data can be read, copie
|
||||
|
||||
## Infrastructure-based attacks
|
||||
|
||||
Malicious cloud users ("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 repeatedly access data over a longer period. Analogously to the *insider access* scenario, Constellation also prevents access to a deployment's data in this scenario.
|
||||
Malicious cloud users ("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. Analogously to the *insider access* scenario, Constellation also prevents access to a deployment's data in this scenario.
|
||||
|
||||
## Supply chain attacks
|
||||
|
||||
Supply chain security is receiving lots of attention recently due to an [increasing number of recorded attacks](https://www.enisa.europa.eu/news/enisa-news/understanding-the-increase-in-supply-chain-security-attacks). For instance, a malicious actor could attempt to tamper Constellation node images (including Kubernetes and other software) before they're loaded in the confidential VMs of a cluster. Constellation uses remote attestation in conjunction with public transparency logs to prevent this. The approach is detailed [here](../architecture/attestation.md).
|
||||
Supply chain security is receiving lots of attention recently due to an [increasing number of recorded attacks](https://www.enisa.europa.eu/news/enisa-news/understanding-the-increase-in-supply-chain-security-attacks). For instance, a malicious actor could attempt to tamper Constellation node images (including Kubernetes and other software) before they're loaded in the confidential VMs of a cluster. Constellation uses [remote attestation](../architecture/attestation.md) in conjunction with public [transparency logs](../workflows/verify-cli.md) to prevent this.
|
||||
|
||||
In the future, Constellation will extend this feature to customer workloads. This will enable cluster owners to create auditable policies that precisely define which containers can run in a given deployment.
|
||||
|
||||
@ -11,7 +11,7 @@ Welcome to the documentation of Constellation! Constellation is a Kubernetes eng
|
||||
Constellation shields your entire Kubernetes cluster from the underlying cloud infrastructure. Everything inside is always encrypted, including at runtime in memory. For this, Constellation leverages a technology called *confidential computing* and more specifically Confidential VMs.
|
||||
|
||||
:::tip
|
||||
See our 📄[whitepaper](https://content.edgeless.systems/hubfs/Confidential%20Computing%20Whitepaper.pdf) for more information on confidential computing.
|
||||
See the 📄[whitepaper](https://content.edgeless.systems/hubfs/Confidential%20Computing%20Whitepaper.pdf) for more information on confidential computing.
|
||||
:::
|
||||
|
||||
## Goals
|
||||
@ -31,4 +31,4 @@ Constellation provides unique security [features](overview/confidential-kubernet
|
||||
|
||||
## Next steps
|
||||
|
||||
You can learn more about the concept of Confidential Kubernetes, features, security benefits, and performance of Constellation in the *Basics* section. To jump right into the action head to *Getting Started*.
|
||||
You can learn more about the concept of Confidential Kubernetes, features, security benefits, and performance of Constellation in the *Basics* section. To jump right into the action head to *Getting started*.
|
||||
|
||||
@ -16,9 +16,9 @@ The following table summarizes the state of features for different infrastructur
|
||||
| **Feature** | **Azure** | **GCP** | **AWS** | **OpenStack (Yoga)** |
|
||||
|-------------------------------|-----------|---------|---------|----------------------|
|
||||
| **1. Custom images** | Yes | Yes | No | Yes |
|
||||
| **2. SEV-SNP or TDX** | Yes | No | No | Depends on Kernel/HV |
|
||||
| **3. Raw guest attestation** | Yes | No | No | Depends on Kernel/HV |
|
||||
| **4. Reviewable firmware** | No* | No | No | Depends on Kernel/HV |
|
||||
| **2. SEV-SNP or TDX** | Yes | No | No | Depends on kernel/HV |
|
||||
| **3. Raw guest attestation** | Yes | No | No | Depends on kernel/HV |
|
||||
| **4. Reviewable firmware** | No* | No | No | Depends on kernel/HV |
|
||||
|
||||
## Microsoft Azure
|
||||
|
||||
@ -36,8 +36,8 @@ AWS currently doesn't offer CVMs. AWS proprietary Nitro Enclaves offer some rela
|
||||
|
||||
## OpenStack
|
||||
|
||||
OpenStack is an open-source cloud and infrastructure management software. It's used by many smaller CSPs and datacenters. In the latest *Yoga* version, OpenStack has basic support for CVMs. However, much depends on the employed Kernel and hypervisor. Features (2)--(4) are likely to be a *Yes* with Linux Kernel version 6.2. Thus, going forward, OpenStack on corresponding AMD or Intel hardware will be a viable underpinning for Constellation.
|
||||
OpenStack is an open-source cloud and infrastructure management software. It's used by many smaller CSPs and datacenters. In the latest *Yoga* version, OpenStack has basic support for CVMs. However, much depends on the employed kernel and hypervisor. Features (2)--(4) are likely to be a *Yes* with Linux kernel version 6.2. Thus, going forward, OpenStack on corresponding AMD or Intel hardware will be a viable underpinning for Constellation.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The different clouds and software like the Linux Kernel and OpenStack are in the process of building out their support for state-of-the-art CVMs. Azure has already most features in place. For Constellation, the status quo means that the TCB has different shapes on different infrastructures. With broad SEV-SNP support coming to the Linux Kernel, we soon expect a normalization of features across infrastructures.
|
||||
The different clouds and software like the Linux kernel and OpenStack are in the process of building out their support for state-of-the-art CVMs. Azure has already most features in place. For Constellation, the status quo means that the TCB has different shapes on different infrastructures. With broad SEV-SNP support coming to the Linux kernel, we soon expect a normalization of features across infrastructures.
|
||||
|
||||
@ -15,8 +15,8 @@ Constellation implements the Confidential Kubernetes concept with the following
|
||||
* **Runtime encryption**: Constellation runs all Kubernetes nodes inside Confidential VMs (CVMs). This gives runtime encryption for the entire cluster.
|
||||
* **Network and storage encryption**: Constellation augments this with transparent encryption of the [network](../architecture/networking.md) and [persistent storage](../architecture/encrypted-storage.md). Thus, workloads and control plane are truly end-to-end encrypted: at rest, in transit, and at runtime.
|
||||
* **Transparent key management**: Constellation manages the corresponding [cryptographic keys](../architecture/keys.md) inside CVMs.
|
||||
* **Node attestation & verification**: Constellation verifies the integrity of each new CVM-based node using [remote attestation](../architecture/attestation.md). Only "good" nodes receive the cryptographic keys required to access the network and storage of a cluster.
|
||||
* **Confidential computing-optimized images**: A node is "good" if it's running a signed Constellation [node image](../architecture/networking.md) inside a CVM and is in the expected state. (Node images are hardware-measured during boot and are reflected. The measurements are reflected in the attestation statements that are produced by nodes and verified by Constellation.)
|
||||
* **Node attestation and verification**: Constellation verifies the integrity of each new CVM-based node using [remote attestation](../architecture/attestation.md). Only "good" nodes receive the cryptographic keys required to access the network and storage of a cluster.
|
||||
* **Confidential computing-optimized images**: A node is "good" if it's running a signed Constellation [node image](../architecture/images.md) inside a CVM and is in the expected state. (Node images are hardware-measured during boot. The measurements are reflected in the attestation statements that are produced by nodes and verified by Constellation.)
|
||||
* **"Whole cluster" attestation**: Towards the DevOps engineer, Constellation provides a single hardware-rooted certificate from which all of the above can be verified.
|
||||
|
||||
With the above, Constellation wraps an entire cluster into one coherent and verifiable *confidential context*. The concept is depicted in the following.
|
||||
@ -29,7 +29,7 @@ In contrast, managed Kubernetes with CVMs, as it's for example offered in [AKS](
|
||||
|
||||
|
||||
|
||||
The following table highlights the key differences in terms of features:
|
||||
The following table highlights the key differences in terms of features.
|
||||
|
||||
| | Managed Kubernetes with CVMs | Confidential Kubernetes (Constellation✨) |
|
||||
|-------------------------------------|------------------------------|--------------------------------------------|
|
||||
|
||||
@ -20,6 +20,6 @@ These terms may be different for future releases.
|
||||
|
||||
### Enterprise License
|
||||
|
||||
Enterprise Licenses don't have the above limitations and come with support and additional features. Find out more [here](https://www.edgeless.systems/products/constellation/).
|
||||
Enterprise Licenses don't have the above limitations and come with support and additional features. Find out more at the [product website](https://www.edgeless.systems/products/constellation/).
|
||||
|
||||
Once you have received your Enterprise License file, place it in your [Constellation workspace](../architecture/orchestration.md#workspaces) in a file named `constellation.license`.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Performance
|
||||
|
||||
This section analyses the performance of Constellation.
|
||||
This section analyzes the performance of Constellation.
|
||||
|
||||
## Performance impact from runtime encryption
|
||||
|
||||
@ -48,7 +48,7 @@ Using the default [K-Bench test configurations](https://github.com/vmware-tanzu/
|
||||
#### Kubernetes API Latency
|
||||
|
||||
At its core, the Kubernetes API is the way to query and modify a cluster's state. Latency matters here. Hence, it's vital that even with the additional level of security from Constellation's network the API latency doesn't spike.
|
||||
K-Bench's `default` test performs calls to the API to create, update and delete cluster resources.
|
||||
K-Bench's `default` test performs calls to the API to create, update, and delete cluster resources.
|
||||
|
||||
The three graphs below compare the API latencies (lower is better) in milliseconds for pods, services, and deployments.
|
||||
|
||||
@ -66,8 +66,8 @@ Deployments: Constellation has the lowest latency for all cases except for scali
|
||||
|
||||
#### Network
|
||||
|
||||
When it comes to network performance, there are two main indicators we need to differentiate: intra-node and inter-node transmission speed.
|
||||
K-Bench provides benchmark tests for both, configured as `dp_netperf_internode`, `dp_network_internode`, `dp_network_intranode`.
|
||||
There are two main indicators for network performance: intra-node and inter-node transmission speed.
|
||||
K-Bench provides benchmark tests for both, configured as `dp_netperf_internode`, `dp_network_internode`, and `dp_network_intranode`.
|
||||
|
||||
##### Inter-node
|
||||
|
||||
@ -83,7 +83,7 @@ The connections directly pass through the node's OS layer and never hit the netw
|
||||
The benchmark evaluates how the [Constellation's node OS image](../architecture/images.md) and runtime encryption influence the throughput.
|
||||
|
||||
The K-Bench tests `dp_network_internode` and `dp_network_intranode`. The tests use [`iperf`](https://iperf.fr/) to measure the bandwidth available.
|
||||
Constellation's bandwidth for both sending and receiving is at 20 Gbps while AKS achieves slightly higher numbers and GKE achieves about 30 Gbps in our tests.
|
||||
Constellation's bandwidth for both sending and receiving is at 20 Gbps while AKS achieves slightly higher numbers and GKE achieves about 30 Gbps in the tests.
|
||||
|
||||
|
||||
|
||||
@ -97,11 +97,11 @@ Similarly, Constellation will provision a PV via a default storage class upon a
|
||||
The K-Bench [`fio`](https://fio.readthedocs.io/en/latest/fio_doc.html) benchmark consists of several tests.
|
||||
We selected four different tests that perform asynchronous access patterns because we believe they most accurately depict real-world I/O access for most applications.
|
||||
|
||||
In the graph below, you will find the I/O throughput in MiB/s - where higher is better.
|
||||
The following graph shows I/O throughput in MiB/s (higher is better).
|
||||
|
||||
|
||||
|
||||
Comparing Constellation on GCP with GKE, we see that Constellation offers similar read/write speeds in all scenarios.
|
||||
Comparing Constellation on GCP with GKE, you see that Constellation offers similar read/write speeds in all scenarios.
|
||||
|
||||
Constellation on Azure and AKS, however, partially differ. Only for the full write mix, Constellation and AKS have similar storage access speeds. In the `70/30 mix`, AKS outperforms Constellation.
|
||||
|
||||
|
||||
@ -7,5 +7,5 @@ From a security perspective, Constellation implements the [Confidential Kubernet
|
||||
From an operational perspective, Constellation provides the following key features:
|
||||
|
||||
* **Native support for different clouds**: Constellation works on Microsoft Azure and Google Cloud Platform (GCP). Support for Amazon Web Services (AWS) and OpenStack-based environments is coming with a future release. Constellation securely interfaces with the cloud infrastructure to provide [cluster autoscaling](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), [dynamic persistent volumes](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/), and [service load balancing](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
|
||||
* **Highly availability**: Constellation combines a [multi-master architecture](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) with a [stacked etcd topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) to ensure high availability.
|
||||
* **High availability**: Constellation uses a [multi-master architecture](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) with a [stacked etcd topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) to ensure high availability.
|
||||
* **Integrated Day-2 operations**: Constellation lets you securely [upgrade](../workflows/upgrade.md) your cluster to a new release. It also lets you securely [recover](../workflows/recovery.md) a failed cluster. Both with a single command.
|
||||
|
||||
@ -13,10 +13,10 @@ This opens up a large attack surface where workloads and data can be read, copie
|
||||
|
||||
## Infrastructure-based attacks
|
||||
|
||||
Malicious cloud users ("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 repeatedly access data over a longer period. Analogously to the *insider access* scenario, Constellation also prevents access to a deployment's data in this scenario.
|
||||
Malicious cloud users ("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. Analogously to the *insider access* scenario, Constellation also prevents access to a deployment's data in this scenario.
|
||||
|
||||
## Supply chain attacks
|
||||
|
||||
Supply chain security is receiving lots of attention recently due to an [increasing number of recorded attacks](https://www.enisa.europa.eu/news/enisa-news/understanding-the-increase-in-supply-chain-security-attacks). For instance, a malicious actor could attempt to tamper Constellation node images (including Kubernetes and other software) before they're loaded in the confidential VMs of a cluster. Constellation uses remote attestation in conjunction with public transparency logs to prevent this. The approach is detailed [here](../architecture/attestation.md).
|
||||
Supply chain security is receiving lots of attention recently due to an [increasing number of recorded attacks](https://www.enisa.europa.eu/news/enisa-news/understanding-the-increase-in-supply-chain-security-attacks). For instance, a malicious actor could attempt to tamper Constellation node images (including Kubernetes and other software) before they're loaded in the confidential VMs of a cluster. Constellation uses [remote attestation](../architecture/attestation.md) in conjunction with public [transparency logs](../workflows/verify-cli.md) to prevent this.
|
||||
|
||||
In the future, Constellation will extend this feature to customer workloads. This will enable cluster owners to create auditable policies that precisely define which containers can run in a given deployment.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user