Ref/docs 2.0 (#112)
@ -1,8 +1,12 @@
|
||||
---
|
||||
slug: /
|
||||
id: intro
|
||||
---
|
||||
# Introduction
|
||||
|
||||
Welcome to the documentation of Constellation! Constellation is a Kubernetes engine that aims to provide the best possible data security.
|
||||
|
||||

|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "constellation-docs",
|
||||
"version": "1.15.0",
|
||||
"version": "2.0.0",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
|
Before Width: | Height: | Size: 288 KiB |
@ -1,127 +0,0 @@
|
||||
# First steps
|
||||
|
||||
The following steps will guide you through the process of creating a cluster and deploying a sample app. This example assumes that you have successfully [installed and set up Constellation](install.md).
|
||||
|
||||
## Create a cluster
|
||||
|
||||
1. Create the configuration file for your selected cloud provider.
|
||||
|
||||
<tabs>
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
On Azure you also need a *user-assigned managed identity* with the [correct permissions](install.md?id=authorization).
|
||||
|
||||
Then execute:
|
||||
|
||||
```bash
|
||||
constellation config generate azure
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
```bash
|
||||
constellation config generate gcp
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
This creates the file `constellation-conf.yaml` in your current working directory. Edit this file to set your cloud subscription IDs and optionally customize further options of your Constellation cluster. All configuration options are documented in this file.
|
||||
|
||||
For more details, see the [reference section](../reference/config.md#required-customizations).
|
||||
|
||||
2. Download the measurements for your configured image.
|
||||
|
||||
```bash
|
||||
constellation config fetch-measurements
|
||||
```
|
||||
|
||||
This command is necessary to download the latest trusted measurements for your configured image.
|
||||
|
||||
For more details, see the [verification section](../workflows/verify.md).
|
||||
|
||||
3. Create the cluster with one control-plane node and two worker nodes. `constellation create` uses options set in `constellation-conf.yaml` automatically.
|
||||
|
||||
<tabs>
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
constellation create azure --control-plane-nodes 1 --worker-nodes 2 --instance-type Standard_D4a_v4 -y
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
```bash
|
||||
constellation create gcp --control-plane-nodes 1 --worker-nodes 2 --instance-type n2d-standard-2 -y
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation create ...
|
||||
Your Constellation cluster was created successfully.
|
||||
```
|
||||
|
||||
4. Initialize the cluster
|
||||
|
||||
```bash
|
||||
constellation init
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation init
|
||||
Creating service account ...
|
||||
Your Constellation cluster was successfully initialized.
|
||||
Constellation cluster's identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
|
||||
Kubernetes configuration constellation-admin.conf
|
||||
You can now connect to your cluster by executing:
|
||||
export KUBECONFIG="$PWD/constellation-admin.conf"
|
||||
```
|
||||
|
||||
The cluster's identifier will be different in your output.
|
||||
Keep `constellation-mastersecret.json` somewhere safe.
|
||||
This will allow you to [recover your cluster](../workflows/recovery.md) in case of a disaster.
|
||||
|
||||
5. Configure kubectl
|
||||
|
||||
```bash
|
||||
export KUBECONFIG="$PWD/constellation-admin.conf"
|
||||
```
|
||||
|
||||
## Deploy a sample application
|
||||
|
||||
1. Deploy the [emojivoto app](https://github.com/BuoyantIO/emojivoto)
|
||||
|
||||
```bash
|
||||
kubectl apply -k github.com/BuoyantIO/emojivoto/kustomize/deployment
|
||||
```
|
||||
|
||||
2. Expose the frontend service locally
|
||||
|
||||
```bash
|
||||
kubectl wait --for=condition=available --timeout=60s -n emojivoto --all deployments
|
||||
kubectl -n emojivoto port-forward svc/web-svc 8080:80 &
|
||||
curl http://localhost:8080
|
||||
kill %1
|
||||
```
|
||||
|
||||
## Terminate your cluster
|
||||
|
||||
```bash
|
||||
constellation terminate
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation terminate
|
||||
Terminating ...
|
||||
Your Constellation cluster was terminated successfully.
|
||||
```
|
@ -1,51 +0,0 @@
|
||||
---
|
||||
slug: /
|
||||
id: intro
|
||||
---
|
||||
|
||||
# Welcome to Constellation! 🎉
|
||||
|
||||
Constellation is the first Confidential Kubernetes platform!
|
||||
Constellation leverages confidential computing to isolate entire Kubernetes clusters and all workloads from the rest of the cloud infrastructure.
|
||||
From the inside, it's a fully-featured, [certified](https://www.cncf.io/certification/software-conformance/), Kubernetes engine.
|
||||
From the outside, it's an end to end isolated, always encrypted stronghold. A Confidential Cloud in the public cloud.
|
||||
Constellation is open source and enterprise-ready, tailored for unleashing the power of confidential computing for all your workloads at scale.
|
||||
|
||||
For a brief introduction to the Confidential Kubernetes concept, read the [introduction](overview/confidential-kubernetes.md).
|
||||
For more elaborate overviews of Constellation's, see the [architecture](architecture/overview.md) section.
|
||||
|
||||

|
||||
|
||||
## Features
|
||||
|
||||
Constellation's main features are:
|
||||
|
||||
* The only cloud agnostic Confidential Kubernetes platform
|
||||
* Verifiable integrity and confidentiality protection of the entire Kubernetes cluster
|
||||
* High-available, enterprise-ready Kubernetes engine
|
||||
* Memory runtime encryption of all Kubernetes nodes
|
||||
* Network encryption for the node to node traffic. Including the pod network.
|
||||
* [Persistent volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) encryption for block storage
|
||||
* Key management for transparent network and storage encryption
|
||||
* CC-optimized, fully measured, and integrity-protected node OS
|
||||
* Kubernetes node attestation
|
||||
* Dynamic cluster autoscaling with autonomous node attestation
|
||||
* Supply chain protection with [sigstore](https://www.sigstore.dev/)
|
||||
|
||||
## Getting started
|
||||
|
||||
Sounds great, how can I try this?
|
||||
|
||||
Constellation can be [deployed](getting-started/install.md) in minutes to your favorite infrastructure provider :rocket:
|
||||
|
||||
## Where does it fit
|
||||
|
||||
Constellation is the Kubernetes platform for secure, confidential cloud computing.
|
||||
When moving workloads to the cloud most enterprises are facing the following challenges:
|
||||
|
||||
* How to **prevent unauthorized access** from hackers, cloud administrators, or governments?
|
||||
* How to **ensure compliance** with privacy laws (e.g. GDPR) and industry-specific regulation (e.g. HIPAA)?
|
||||
* How to **implement cloud security at the root** -- without simply adding "yet another tool"?
|
||||
|
||||
Constellation is designed to fundamentally change the playing field when it comes to cloud migration.
|
||||
By leveraging confidential computing hardware capabilities it solves these challenges at the root.
|
@ -1,122 +0,0 @@
|
||||
# Performance
|
||||
|
||||
Security and performance are generally considered to be in a tradeoff relationship.
|
||||
A tradeoff is a situation that involves losing one quality or aspect of something in return for gaining another quality or aspect.
|
||||
Encryption is one of the common suspects for such a tradeoff that's inevitable for upholding the confidentiality and privacy of data during cloud transformation.
|
||||
Constellation provides encryption [of data at rest](../architecture/encrypted-storage.md), [in-cluster transit](../architecture/networking.md), and [in-use](confidential-kubernetes.md) of a Kubernetes cluster.
|
||||
This article elaborates on the performance impact for applications deployed in Constellation versus standard Kubernetes clusters.
|
||||
|
||||
AMD and Azure have collaboratively released a [performance benchmark](https://community.amd.com/t5/business/microsoft-azure-confidential-computing-powered-by-3rd-gen-epyc/ba-p/497796) for the runtime encryption of the 3rd Gen AMD EPYC processors with its SEV-SNP capability enabled.
|
||||
They found that Confidential VMs have minimal performance differences on common benchmarks as compared with general-purpose VMs.
|
||||
The overhead being in the single digits, runtime memory encryption will affect only the compute-heavy applications in their performance.
|
||||
Confidential VMs such as AMD SEV-SNP are the foundation for Constellation, hence, the same performance results can be expected in terms of runtime overhead.
|
||||
|
||||
We performed additional benchmarking tests on Constellation clusters to assess more Kubernetes-specific intra-cluster network throughput, storage I/O, and Kubernetes API latencies.
|
||||
|
||||
## Test Setup
|
||||
|
||||
We benchmarked Constellation release v1.3.0 using [K-Bench](https://github.com/vmware-tanzu/k-bench). K-Bench is a configurable framework to benchmark Kubernetes clusters in terms of storage I/O, network performance, and creating/scaling resources.
|
||||
|
||||
As a baseline, we compared Constellation with the Constellation-supported cloud providers' managed Kubernetes offerings.
|
||||
|
||||
Throughout this article, you will find the comparison of Constellation on GCP with GKE and on Azure with AKS.
|
||||
We can't provide an accurate intercloud meta-comparison at this point due to different Confidential VM machine types.
|
||||
|
||||
The benchmark ran with the following machines and configurations:
|
||||
|
||||
### Constellation on GCP / GKE
|
||||
|
||||
- Nodes: 3
|
||||
- Machines: `n2d-standard-2`
|
||||
- Kubernetes version: `1.23.6-gke.2200`
|
||||
- Zone: `europe-west3-b`
|
||||
|
||||
### Constellation on Azure / AKS
|
||||
|
||||
- Nodes: 3
|
||||
- Machines: `D2a_v4`
|
||||
- Kubernetes version: `1.23.5`
|
||||
- Region: `North Europe`
|
||||
- Zone: `2`
|
||||
|
||||
### K-Bench
|
||||
|
||||
Using the default [K-Bench test configurations](https://github.com/vmware-tanzu/k-bench/tree/master/config), we ran the following tests on the clusters:
|
||||
|
||||
- `default`
|
||||
- `dp_netperf_internode`
|
||||
- `dp_network_internode`
|
||||
- `dp_network_intranode`
|
||||
- `dp_fio`
|
||||
|
||||
## Results
|
||||
|
||||
### 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.
|
||||
|
||||
The three graphs below compare the API latencies (lower is better) in milliseconds for pods, services, and deployments.
|
||||
|
||||

|
||||
|
||||
Pods: Except for the `Pod Update` call, Constellation is faster than AKS and GKE in terms of API calls.
|
||||
|
||||

|
||||
|
||||
Services: Constellation has lower latencies than AKS and GKE except for service creation on AKS.
|
||||
|
||||

|
||||
|
||||
Deployments: Constellation has the lowest latency for all cases except for scaling deployments on GKE and creating deployments on AKS.
|
||||
|
||||
### 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`.
|
||||
|
||||
#### Inter-node
|
||||
|
||||
K-Bench has two benchmarks to evaluate the network performance between different nodes.
|
||||
|
||||
The first test (`dp_netperf_internode`) uses [`netperf`](https://hewlettpackard.github.io/netperf/) to measure the throughput. Constellation has a slightly lower network throughput than AKS and GKE.
|
||||
This can largely be attributed to [Constellation's network encryption](../architecture/networking.md).
|
||||
|
||||
#### Intra-node
|
||||
|
||||
Intra-node communication happens between pods running on the same node.
|
||||
The connections directly pass through the node's OS layer and never hit the network.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
### Storage I/O
|
||||
|
||||
Azure and GCP offer persistent storage for their Kubernetes services AKS and GKE via the Container Storage Interface (CSI). CSI storage in Kubernetes is available via `PersistentVolumes` (`PV`) and consumed via `PersistentVolumeClaims` (`PVC`).
|
||||
Upon requesting persistent storage through a PVC, GKE and AKS will provision a PV as defined by a default [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/).
|
||||
Constellation provides persistent storage on Azure and GCP that's encrypted on the CSI layer. Read more about this in [how Constellation encrypts data at rest](../architecture/encrypted-storage.md).
|
||||
Similarly, Constellation will provision a PV via a default storage class upon a PVC request.
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
Comparing Constellation on GCP with GKE, we see that Constellation offers similar read/write speeds in all scenarios.
|
||||
|
||||
Constellation on Azure and AKS, however, differ in sometimes. As you can see, only for the full write mix, Constellation and AKS have similar storage access speeds. In the 70/30 mix, AKS outperforms Constellation.
|
||||
|
||||
Note: For the sequential reads with a 0/100 read-write mix, no data could be measured on AKS, hence the missing data bar.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Constellation can help transform the way organizations process data in the cloud by delivering high-performance Kubernetes while preserving confidentiality and privacy.
|
||||
As demonstrated in our tests above, Constellation provides a Kubernetes cluster with minimal performance impact compared to the managed Kubernetes offerings AKS and GKE.
|
||||
While enabling always encrypted processing of data, the network and storage encryption comes at a minimal price.
|
||||
Constellation holds up in most benchmarks but in certain scenarios can be slightly lower in terms of storage and network throughput.
|
||||
Kubernetes API latencies aren’t affected, and Constellation even outperforms AKS and GKE in this aspect.
|
@ -1,21 +0,0 @@
|
||||
# Product features
|
||||
|
||||
Constellation is a confidential orchestration platform, designed to be the most secure way to run Kubernetes.
|
||||
It leverages confidential computing to isolate entire Kubernetes deployments and all workloads from the infrastructure.
|
||||
From the inside, a Constellation cluster feels 100% like Kubernetes as you know it.
|
||||
But for everyone else, from the outside, it’s runtime-encrypted VMs talking over encrypted channels and writing encrypted data.
|
||||
|
||||
Constellation provides confidential computing enhancements to Kubernetes, including the following:
|
||||
|
||||
* Leveraging confidential VMs (CVMs) available in all major clouds to isolate and encrypt the Kubernetes control-plane and worker nodes.
|
||||
* Node attestation including a [verified boot](../architecture/images.md#measured-boot) that roots in hardware-measured attestation provided by CVM technologies.
|
||||
* Operating a [container network interface (CNI) plugin](../architecture/networking.md) between CVMs for encrypted network communications in your cluster. Enabling TLS offloading.
|
||||
* [CVM-level persistent volume encryption](../architecture//encrypted-storage.md) ensures the confidentiality and integrity of persistent data outside of the Kubernetes cluster.
|
||||
* [Confidential key management](../architecture//keys.md).
|
||||
* Verifiable, measured, and authenticated [updates](../architecture/orchestration.md#upgrades) of node OS images and Kubernetes components.
|
||||
|
||||
Constellation provides an enterprise-ready Kubernetes environment with key features such as:
|
||||
|
||||
* Multi-cloud deployments. You can deploy Constellation clusters to all major cloud platforms for a consistent confidential orchestration platform.
|
||||
* Highly available (HA) Confidential Kubernetes cluster with [stacked etcd topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology).
|
||||
* Integrating with the Kubernetes cloud controller manager (CCM) to securely provide cloud services such as [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).
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 91 KiB After Width: | Height: | Size: 91 KiB |
Before Width: | Height: | Size: 104 KiB After Width: | Height: | Size: 104 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 138 KiB After Width: | Height: | Size: 138 KiB |
Before Width: | Height: | Size: 257 KiB After Width: | Height: | Size: 257 KiB |
BIN
docs/versioned_docs/version-2.0/_media/product-overview-dark.png
Normal file
After Width: | Height: | Size: 154 KiB |
BIN
docs/versioned_docs/version-2.0/_media/product-overview.png
Normal file
After Width: | Height: | Size: 156 KiB |
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
Before Width: | Height: | Size: 237 KiB After Width: | Height: | Size: 237 KiB |
@ -124,7 +124,7 @@ Constellation allows to specify in the [config](../reference/config.md) which me
|
||||
Enforcing non-reproducible measurements controlled by the cloud provider means that changes in these values require manual updates to the cluster's config.
|
||||
By default, Constellation only enforces measurements that are stable values produced by the infrastructure or by Constellation directly.
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
Constellation leverages the [vTPM](https://docs.microsoft.com/en-us/azure/virtual-machines/trusted-launch#vtpm) feature of Azure CVMs for runtime measurements.
|
||||
@ -147,7 +147,7 @@ The latter means that value can be generated offline and compared to the one in
|
||||
| 7 | Secure Boot State | Azure, Constellation Bootloader | No |
|
||||
| 8 | Kernel command line, GRUB config | Constellation Bootloader | Yes |
|
||||
| 9 | Kernel, initramfs | Constellation Bootloader | Yes |
|
||||
| 10 | Reserved | - | Yes |
|
||||
| 10 | Reserved | - | No |
|
||||
| 11 | Reserved | Constellation Bootstrapper | Yes |
|
||||
| 12 | ClusterID | Constellation Bootstrapper | Yes |
|
||||
| 13–23 | Unused | - | - |
|
||||
@ -177,7 +177,7 @@ The latter means that value can be generated offline and compared to the one in
|
||||
| 7 | GCP Secure Boot Policy | GCP, Constellation Bootloader | No |
|
||||
| 8 | Kernel command line, GRUB config | Constellation Bootloader | Yes |
|
||||
| 9 | Kernel, initramfs | Constellation Bootloader | Yes |
|
||||
| 10 | Reserved | Constellation Bootstrapper | Yes |
|
||||
| 10 | Reserved | - | No |
|
||||
| 11 | Reserved | Constellation Bootstrapper | Yes |
|
||||
| 12 | ClusterID | Constellation Bootstrapper | Yes |
|
||||
| 13–23 | Unused |- | - |
|
||||
@ -233,5 +233,5 @@ flowchart LR
|
||||
B[CLI]-- "contains" -->D["Public Key"]
|
||||
A[Edgeless]-- "signs" -->E["Runtime measurements"]
|
||||
D["Public Key"]-- "verifies" -->E["Runtime measurements"]
|
||||
E["Runtime measurements"]-- "verify" -->F["Constellation cluster"]
|
||||
E["Runtime measurements"]-- "verify" -->F["Constellation cluster"]
|
||||
```
|
267
docs/versioned_docs/version-2.0/getting-started/first-steps.md
Normal file
@ -0,0 +1,267 @@
|
||||
# First steps
|
||||
|
||||
The following steps will guide you through the process of creating a cluster and deploying a sample app. This example assumes that you have successfully [installed and set up Constellation](install.md).
|
||||
|
||||
## Create a cluster
|
||||
|
||||
1. Create the configuration file for your selected cloud provider.
|
||||
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
constellation config generate azure
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP">
|
||||
|
||||
```bash
|
||||
constellation config generate gcp
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
This creates the file `constellation-conf.yaml` in your current working directory.
|
||||
|
||||
2. Fill in your cloud provider specific information:
|
||||
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure (CLI)" default>
|
||||
|
||||
For a quick start it's recommended to use our `az` script to automatically create all required resources:
|
||||
|
||||
```bash
|
||||
RESOURCE_GROUP=constellation # enter name of resource group here
|
||||
LOCATION=westus # enter location of resources here
|
||||
SUBSCRIPTION_ID=$(az account show --query id --out tsv)
|
||||
SERVICE_PRINCIPLE_NAME=constell
|
||||
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
|
||||
az group create --name "${RESOURCE_GROUP}-identity" --location "${LOCATION}"
|
||||
az ad sp create-for-rbac -n "${SERVICE_PRINCIPLE_NAME}" --role Owner --scopes "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}" | tee azureServiceAccountKey.json
|
||||
az identity create -g "${RESOURCE_GROUP}-identity" -n "${SERVICE_PRINCIPLE_NAME}"
|
||||
identityID=$(az identity show -n "${SERVICE_PRINCIPLE_NAME}" -g "${RESOURCE_GROUP}-identity" --query principalId --out tsv)
|
||||
az role assignment create --assignee-principal-type ServicePrincipal --assignee-object-id "${identityID}" --role 'Virtual Machine Contributor' --scope "/subscriptions/${SUBSCRIPTION_ID}"
|
||||
az role assignment create --assignee-principal-type ServicePrincipal --assignee-object-id "${identityID}" --role 'Application Insights Component Contributor' --scope "/subscriptions/${SUBSCRIPTION_ID}"
|
||||
echo "subscription: ${SUBSCRIPTION_ID}"
|
||||
echo "tenant: $(az account show --query tenantId -o tsv)"
|
||||
echo "location: ${LOCATION}"
|
||||
echo "resourceGroup: ${RESOURCE_GROUP}"
|
||||
echo "userAssignedIdentity: $(az identity show -n "${SERVICE_PRINCIPLE_NAME}" -g "${RESOURCE_GROUP}-identity" --query id --out tsv)"
|
||||
echo "appClientID: $(jq -r '.appId' azureServiceAccountKey.json)"
|
||||
echo "clientSecretValue: $(jq -r '.password' azureServiceAccountKey.json)"
|
||||
```
|
||||
|
||||
Fill in the printed out values to your configuration file.
|
||||
|
||||
By default, Constellation uses `Standard_DC4as_v5` CVMs (4 vCPUs, 16 GB RAM) to create your cluster. Optionally, you can switch to a different VM type by modifying **instanceType** in the configuration file.
|
||||
|
||||
For CVMs, any VM type with a minimum of 4 vCPUs from the [DCasv5 & DCadsv5](https://docs.microsoft.com/en-us/azure/virtual-machines/dcasv5-dcadsv5-series) or [ECasv5 & ECadsv5](https://docs.microsoft.com/en-us/azure/virtual-machines/ecasv5-ecadsv5-series) families is supported.
|
||||
|
||||
If you decide to use [trusted launch VMs](../workflows/trusted-launch.md) instead, set **confidentialVM** to false. Afterward, you can use any VMs with a minimum of 4 vCPUs from the [Dav4 & Dasv4](https://docs.microsoft.com/en-us/azure/virtual-machines/dav4-dasv4-series) or [Eav4 & Easv4](https://docs.microsoft.com/en-us/azure/virtual-machines/eav4-easv4-series) families.
|
||||
|
||||
Run `constellation config instance-types` to get the list of all supported options.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="azure-portal" label="Azure (Portal)">
|
||||
|
||||
* **subscription**: Is the UUID of your Azure subscription, e.g., `8b8bd01f-efd9-4113-9bd1-c82137c32da7`.
|
||||
|
||||
You can view your subscription UUID via `az account show` and read the `id` field. For more information refer to [Azure's documentation](https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-subscription).
|
||||
|
||||
* **tenant**: Is the UUID of your Azure tenant, e.g., `3400e5a2-8fe2-492a-886c-38cb66170f25`.
|
||||
|
||||
You can view your tenant UUID via `az account show` and read the `tenant` field. For more information refer to [Azure's documentation](https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-ad-tenant).
|
||||
|
||||
* **location**: Is the Azure datacenter location you want to deploy your cluster in, e.g., `westus`. Notice that CVMs are currently only supported in a few regions, check [Azure's products available by region](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=virtual-machines®ions=all). Currently these are supported:
|
||||
|
||||
* `westus`
|
||||
* `eastus`
|
||||
* `northeurope`
|
||||
* `westeurope`
|
||||
|
||||
* **instanceType**: Is the VM type you want to use for your Constellation nodes.
|
||||
|
||||
For CVMs, any type with a minimum of 4 vCPUs from the [DCasv5 & DCadsv5](https://docs.microsoft.com/en-us/azure/virtual-machines/dcasv5-dcadsv5-series) or [ECasv5 & ECadsv5](https://docs.microsoft.com/en-us/azure/virtual-machines/ecasv5-ecadsv5-series) families is supported. It defaults to `Standard_DC4as_v5` (4 vCPUs, 16 GB RAM).
|
||||
|
||||
If you decide to use [trusted launch VMs](../workflows/trusted-launch.md) instead, set **confidentialVM** to false. Afterward, you can use any VMs with a minimum of 4 vCPUs from the [Dav4 & Dasv4](https://docs.microsoft.com/en-us/azure/virtual-machines/dav4-dasv4-series) or [Eav4 & Easv4](https://docs.microsoft.com/en-us/azure/virtual-machines/eav4-easv4-series) families.
|
||||
|
||||
Run `constellation config instance-types` to get the list of all supported options.
|
||||
|
||||
* **resourceGroup**: [Create a new resource group in Azure](https://portal.azure.com/#create/Microsoft.ResourceGroup), to deploy your Constellation cluster into. Afterwards set the configuration field to the name of the created resource group, e.g., `constellation`.
|
||||
|
||||
* **userAssignedIdentity**: [Create a new managed identity in Azure](https://portal.azure.com/#create/Microsoft.ManagedIdentity). Notice that the identity should be created in a different resource group as all resources within the cluster resource group will be deleted on cluster termination.
|
||||
|
||||
After creation, add two role assignments to the identity, for the roles `Virtual Machine Contributor` and `Application Insights Component Contributor`. The `scope` of both should refer to the previously created resource group.
|
||||
|
||||
Set the configuration value to the full ID of the created identity, e.g., `/subscriptions/8b8bd01f-efd9-4113-9bd1-c82137c32da7/resourcegroups/constellation-identity/providers/Microsoft.ManagedIdentity/userAssignedIdentities/constellation-identity`.
|
||||
|
||||
The user-assigned identity is used by instances of the cluster to access other cloud resources.
|
||||
|
||||
For more information about managed identities refer to [Azure's documentation](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities).
|
||||
|
||||
* **appClientID**: [Create a new app registration in Azure](https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade/quickStartType~/null/isMSAApp~/false).
|
||||
|
||||
As `Supported account types` choose `Accounts in this organizational directory only`, and leave the `Redirect URI` empty.
|
||||
|
||||
In the cluster resource group, go to `Access Control (IAM)`, and set the created app registration as `Owner`.
|
||||
|
||||
Set the configuration value to the `Application (client) ID`, e.g., `86ec31dd-532b-4a8c-a055-dd23f25fb12f`.
|
||||
|
||||
* **clientSecretValue**: In our previously created app registration, go to `Certificates & secrets` and create a new `Client secret`.
|
||||
|
||||
Set the configuration value to the secret value.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP (CLI)">
|
||||
|
||||
For a quick start it's recommended to use our `gcloud` script to automatically create all required resources:
|
||||
|
||||
```bash
|
||||
SERVICE_ACCOUNT_ID=constell # enter name of service account here
|
||||
PROJECT_ID= # enter project id here
|
||||
SERVICE_ACCOUNT_EMAIL=${SERVICE_ACCOUNT_ID}@${PROJECT_ID}.iam.gserviceaccount.com
|
||||
gcloud iam service-accounts create "${SERVICE_ACCOUNT_ID}" --description="Service account used inside Constellation" --display-name="Constellation service account" --project="${PROJECT_ID}"
|
||||
gcloud projects add-iam-policy-binding "${PROJECT_ID}" --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" --role='roles/compute.instanceAdmin.v1'
|
||||
gcloud projects add-iam-policy-binding "${PROJECT_ID}" --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" --role='roles/compute.networkAdmin'
|
||||
gcloud projects add-iam-policy-binding "${PROJECT_ID}" --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" --role='roles/compute.securityAdmin'
|
||||
gcloud projects add-iam-policy-binding "${PROJECT_ID}" --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" --role='roles/compute.storageAdmin'
|
||||
gcloud projects add-iam-policy-binding "${PROJECT_ID}" --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" --role='roles/iam.serviceAccountUser'
|
||||
gcloud iam service-accounts keys create gcpServiceAccountKey.json --iam-account="${SERVICE_ACCOUNT_EMAIL}"
|
||||
echo "project: ${PROJECT_ID}"
|
||||
echo "serviceAccountKeyPath: $(realpath gcpServiceAccountKey.json)"
|
||||
```
|
||||
|
||||
Fill in the printed out values to your configuration file.
|
||||
|
||||
By default, Constellation uses `n2d-standard-4` VMs (4 vCPUs, 16 GB RAM) to create your cluster. Optionally, you can switch to a different VM type by modifying **instanceType** in the configuration file. Supported are all machines from the N2D family. Refer to [N2D machine series](https://cloud.google.com/compute/docs/general-purpose-machines#n2d_machines) or run `constellation config instance-types` to get the list of all supported options.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp-console" label="GCP (Console)">
|
||||
|
||||
* **project**: Is the ID of your GCP project, e.g., `constellation-129857`.
|
||||
|
||||
You will find it on the [welcome screen of your GCP project](https://console.cloud.google.com/welcome). For more information refer to [Google's documentation](https://support.google.com/googleapi/answer/7014113).
|
||||
|
||||
* **region**: Is the GCP region you want to deploy your cluster in, e.g., `us-west-1`.
|
||||
|
||||
You can find a [list of all regions in Google's documentation](https://cloud.google.com/compute/docs/regions-zones#available).
|
||||
|
||||
* **zone**: Is the GCP zone you want to deploy your cluster in, e.g., `us-west-1a`.
|
||||
|
||||
You can find a [list of all zones in Google's documentation](https://cloud.google.com/compute/docs/regions-zones#available).
|
||||
|
||||
* **instanceType**: Is the VM type you want to use for your Constellation nodes.
|
||||
|
||||
Supported are all machines from the N2D family. It defaults to `n2d-standard-4` (4 vCPUs, 16 GB RAM), but you can use any other VMs from the same family. Refer to [N2D machine series](https://cloud.google.com/compute/docs/general-purpose-machines#n2d_machines) or run `constellation config instance-types` to get the list of all supported options.
|
||||
|
||||
* **serviceAccountKeyPath**: To configure this, you need to create a GCP [service account](https://cloud.google.com/iam/docs/service-accounts) with the following permissions:
|
||||
|
||||
- `Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)`
|
||||
- `Compute Network Admin (roles/compute.networkAdmin)`
|
||||
- `Compute Security Admin (roles/compute.securityAdmin)`
|
||||
- `Compute Storage Admin (roles/compute.storageAdmin)`
|
||||
- `Service Account User (roles/iam.serviceAccountUser)`
|
||||
|
||||
Afterwards, create and download a new `JSON` key for this service account. Place the downloaded file in your Constellation workspace, and set the config parameter to the filename, e.g., `constellation-129857-15343dba46cb.json`.
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
3. Download the measurements for your configured image.
|
||||
|
||||
```bash
|
||||
constellation config fetch-measurements
|
||||
```
|
||||
|
||||
This command is necessary to download the latest trusted measurements for your configured image.
|
||||
|
||||
For more details, see the [verification section](../workflows/verify.md).
|
||||
|
||||
4. Create the cluster with one control-plane node and two worker nodes. `constellation create` uses options set in `constellation-conf.yaml` automatically.
|
||||
|
||||
:::tip
|
||||
|
||||
On Azure, after creating a user-assigned managed identity and app registration, Azure AD needs time to propagate permissions to different regions due to replication lag. To avoid permission errors, it's recommended to wait at least 15 minutes after role assignments before creating the cluster.
|
||||
|
||||
:::
|
||||
|
||||
```bash
|
||||
constellation create --control-plane-nodes 1 --worker-nodes 2 -y
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation create ...
|
||||
Your Constellation cluster was created successfully.
|
||||
```
|
||||
|
||||
5. Initialize the cluster
|
||||
|
||||
```bash
|
||||
constellation init
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation init
|
||||
Creating service account ...
|
||||
Your Constellation cluster was successfully initialized.
|
||||
Constellation cluster's identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
|
||||
Kubernetes configuration constellation-admin.conf
|
||||
You can now connect to your cluster by executing:
|
||||
export KUBECONFIG="$PWD/constellation-admin.conf"
|
||||
```
|
||||
|
||||
The cluster's identifier will be different in your output.
|
||||
Keep `constellation-mastersecret.json` somewhere safe.
|
||||
This will allow you to [recover your cluster](../workflows/recovery.md) in case of a disaster.
|
||||
|
||||
6. Configure kubectl
|
||||
|
||||
```bash
|
||||
export KUBECONFIG="$PWD/constellation-admin.conf"
|
||||
```
|
||||
|
||||
## Deploy a sample application
|
||||
|
||||
1. Deploy the [emojivoto app](https://github.com/BuoyantIO/emojivoto)
|
||||
|
||||
```bash
|
||||
kubectl apply -k github.com/BuoyantIO/emojivoto/kustomize/deployment
|
||||
```
|
||||
|
||||
2. Expose the frontend service locally
|
||||
|
||||
```bash
|
||||
kubectl wait --for=condition=available --timeout=60s -n emojivoto --all deployments
|
||||
kubectl -n emojivoto port-forward svc/web-svc 8080:80 &
|
||||
curl http://localhost:8080
|
||||
kill %1
|
||||
```
|
||||
|
||||
## Terminate your cluster
|
||||
|
||||
```bash
|
||||
constellation terminate
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation terminate
|
||||
Terminating ...
|
||||
Your Constellation cluster was terminated successfully.
|
||||
```
|
||||
|
||||
In case you have used `az` CLI to create your environment, make sure to clean up afterwards:
|
||||
|
||||
```bash
|
||||
APPID=$(jq -r '.appId' azureServiceAccountKey.json)
|
||||
az ad sp delete --id "${APPID}"
|
||||
az group delete -g "${RESOURCE_GROUP}-identity" --yes --no-wait
|
||||
az group delete -g "${RESOURCE_GROUP}" --yes --no-wait
|
||||
```
|
@ -15,7 +15,7 @@ Before we start, make sure the following requirements are fulfilled:
|
||||
|
||||
## Install the Constellation CLI
|
||||
|
||||
The Constellation CLI can be downloaded from our [release page](https://github.com/edgelesssys/constellation/releases). Therefore, navigate to a release and download the file `constellation`. Move the downloaded file to a directory in your `PATH` (default: `/usr/local/bin`) and make it executable by entering `chmod s+x constellation` in your terminal.
|
||||
The Constellation CLI can be downloaded from our [release page](https://github.com/edgelesssys/constellation/releases). Therefore, navigate to a release and download the `constellation` binary for your operating system and architecture. Move the downloaded file to a directory in your `PATH` (default: `/usr/local/bin`) and make it executable by entering `chmod u+x constellation` in your terminal.
|
||||
|
||||
Running `constellation` should then give you:
|
||||
|
||||
@ -38,7 +38,7 @@ The Constellation CLI supports autocompletion for various shells. To set it up,
|
||||
For extra security, make sure to verify your CLI. Therefore, install [cosign](https://github.com/sigstore/cosign). Then, head to our [release page](https://github.com/edgelesssys/constellation/releases) again and, from the same release as before, download the following files:
|
||||
|
||||
- `cosign.pub` (Edgeless System's cosign public key)
|
||||
- `constellation.sig` (the CLI's signature)
|
||||
- `constellation-*.sig` (the CLI's signature)
|
||||
|
||||
You can then verify your CLI before launching a cluster using the paths to the public key, signature, and CLI executable:
|
||||
|
||||
@ -62,7 +62,7 @@ Don't use the testing methods for setting up a production-grade Constellation cl
|
||||
|
||||
:::
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
**Testing**
|
||||
@ -116,7 +116,7 @@ For production clusters, use one of the following options on a trusted machine:
|
||||
|
||||
### Authorization
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
Your user account needs the following permissions to set up a Constellation cluster:
|
||||
@ -124,46 +124,16 @@ Your user account needs the following permissions to set up a Constellation clus
|
||||
- `Contributor`
|
||||
- `User Access Administrator`
|
||||
|
||||
Additionally, you need to [create a user-assigned managed identity](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities) with the following roles:
|
||||
|
||||
- `Virtual Machine Contributor`
|
||||
- `Application Insights Component Contributor`
|
||||
|
||||
The user-assigned identity is used by the instances of the cluster to access other cloud resources.
|
||||
|
||||
You also need an empty resource group per cluster. Notice that the user-assigned identity has to be created in a
|
||||
different resource group as all resources within the cluster resource group will be deleted on cluster termination.
|
||||
|
||||
Last, you need to [create an Active Directory app registration](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#register-an-application) (you don't need to add a redirect URI).
|
||||
As supported account types choose 'Accounts in this organizational directory only'. Then [create a client secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#option-2-create-a-new-application-secret), which will be used by Kubernetes.
|
||||
On the cluster resource group, [add the app registration](https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal?tabs=current#step-2-open-the-add-role-assignment-page)
|
||||
with role `Owner`.
|
||||
|
||||
User-assigned identity, cluster resource group, app registration client ID and client secret value need to be set in the `constellation-conf.yaml` configuration file.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
Your user account needs the following permissions to set up a Constellation:
|
||||
|
||||
- `compute.*` (or the subset defined by `roles/compute.instanceAdmin.v1`)
|
||||
- `iam.serviceAccountUser`
|
||||
|
||||
Follow Google's guide on [understanding](https://cloud.google.com/iam/docs/understanding-roles) and [assigning roles](https://cloud.google.com/iam/docs/granting-changing-revoking-access).
|
||||
|
||||
Additionally, you need a service account with the following permissions:
|
||||
|
||||
- `Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)`
|
||||
- `Compute Network Admin (roles/compute.networkAdmin)`
|
||||
- `Compute Security Admin (roles/compute.securityAdmin)`
|
||||
- `Compute Storage Admin (roles/compute.storageAdmin)`
|
||||
- `Service Account User (roles/iam.serviceAccountUser)`
|
||||
|
||||
The key for this service account is passed to the CLI and used by Kubernetes to authenticate with the cloud.
|
||||
You can configure the path to the key in the `constellation-conf.yaml` configuration file.
|
||||
|
||||
GCP instances come with a [default service account](https://cloud.google.com/iam/docs/service-accounts#default) attached
|
||||
that's used by the instances to access the cloud resources of the cluster. You don't need to configure it.
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
34
docs/versioned_docs/version-2.0/intro.md
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
slug: /
|
||||
id: intro
|
||||
---
|
||||
# Introduction
|
||||
|
||||
Welcome to the documentation of Constellation! Constellation is a Kubernetes engine that aims to provide the best possible data security.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
:::
|
||||
|
||||
## Goals
|
||||
|
||||
From a security perspective, Constellation is designed to keep all data always encrypted and to prevent any access from the underlying (cloud) infrastructure. This includes access from datacenter employees, privileged cloud admins, and attackers coming through the infrastructure. Such attackers could be malicious co-tenants escalating their privileges or hackers who managed to compromise a cloud server.
|
||||
|
||||
From a DevOps perspective, Constellation is designed to work just like what you would expect from a modern Kubernetes engine.
|
||||
|
||||
## Use cases
|
||||
|
||||
Constellation provides unique security [features](overview/confidential-kubernetes.md) and [benefits](overview/security-benefits.md). The core use cases are:
|
||||
|
||||
* Increasing the overall security of your clusters
|
||||
* Increasing the trustworthiness of your SaaS offerings
|
||||
* Moving sensitive workloads from on-prem to the cloud
|
||||
* Meeting regulatory requirements
|
||||
|
||||
## 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*.
|
43
docs/versioned_docs/version-2.0/overview/clouds.md
Normal file
@ -0,0 +1,43 @@
|
||||
# Feature status of clouds
|
||||
|
||||
What works on which cloud? Currently, Confidential VMs (CVMs) are available in varying quality on the different clouds and software stacks.
|
||||
|
||||
For Constellation, the ideal environment provides the following:
|
||||
|
||||
1. Ability to run arbitrary software and images inside CVMs
|
||||
2. CVMs based on AMD SEV-SNP (available in EPYC CPUs since the Milan generation) or, in the future, Intel TDX (available in Xeon CPUs from the Sapphire Rapids generation onward)
|
||||
3. Ability for CVM guests to obtain raw attestation statements directly from the CPU, ideally via a TPM-like interface
|
||||
4. Reviewable, open-source firmware inside CVMs
|
||||
|
||||
(1) is a functional must-have. (2)--(4) are required for remote attestation that fully keeps the infrastructure/cloud out. Constellation can work without them or with approximations, but won't protect against certain privileged attackers anymore.
|
||||
|
||||
The following table summarizes the state of features for different infrastructures as of September 2022.
|
||||
|
||||
| **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 |
|
||||
|
||||
## Microsoft Azure
|
||||
|
||||
With its [CVM offering](https://docs.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview), Azure provides the best foundations for Constellation. Regarding (3), Azure provides direct access to remote-attestation statements. However, regarding (4), the standard CVMs still include closed-source firmware running in VM Privilege Level (VMPL) 0. This firmware is signed by Azure. The signature is reflected in the remote-attestation statements of CVMs. Thus, the Azure closed-source firmware becomes part of Constellation's trusted computing base (TCB).
|
||||
|
||||
Recently, Azure [announced](https://techcommunity.microsoft.com/t5/azure-confidential-computing/azure-confidential-vms-using-sev-snp-dcasv5-ecasv5-are-now/ba-p/3573747) the *limited preview* of CVMs with customizable firmware. With this CVM type, (4) switches from *No* to *Yes*. Constellation will support customizable firmware on Azure in the future.
|
||||
|
||||
## Google Cloud Platform (GCP)
|
||||
|
||||
The [CVMs available in GCP](https://cloud.google.com/compute/confidential-vm/docs/create-confidential-vm-instance) are based on AMD SEV but don't have SNP features enabled. This impacts attestation capabilities. Currently, GCP doesn't offer CVM-based attestation at all. Instead, GCP provides attestation statements based on its regular [vTPM](https://cloud.google.com/blog/products/identity-security/virtual-trusted-platform-module-for-shielded-vms-security-in-plaintext), which is managed by the hypervisor. On GCP, the hypervisor is thus currently part of Constellation's TCB.
|
||||
|
||||
## Amazon Web Services (AWS)
|
||||
|
||||
AWS currently doesn't offer CVMs. AWS proprietary Nitro Enclaves offer some related features, but [are explicitly not designed to keep AWS itself out](https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/). An experimental version of Constellation exists that runs on Nitro Enclaves.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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.
|
@ -6,12 +6,25 @@ We use the term *Confidential Kubernetes* to refer to the concept of using confi
|
||||
2. **Control plane shielding**: the confidentiality and integrity of the cluster's control plane, state, and workload configuration are enforced.
|
||||
3. **Attestation and verifiability**: the two properties above can be verified remotely based on hardware-rooted cryptographic certificates.
|
||||
|
||||
Each of the above properties is equally important. Only with all three in conjunction, an entire cluster can be shielded without gaps. This is what Constellation is about.
|
||||
Each of the above properties is equally important. Only with all three in conjunction, an entire cluster can be shielded without gaps.
|
||||
|
||||
Constellation's approach is to run all nodes of the Kubernetes cluster inside Confidential VMs (CVMs). This gives runtime encryption for the entire cluster. Constellation augments this with transparent encryption of the [network](../architecture/keys.md#network-encryption) and [storage](../architecture/encrypted-storage.md). Thus, workloads and control plane are truly end-to-end encrypted: at rest, in transit, and at runtime. Constellation manages the corresponding [cryptographic keys](../architecture/keys.md) inside CVMs. 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. (A node is "good" if it's running a signed Constellation image inside a CVM and is in the expected state.) Towards the DevOps engineer, Constellation provides a single hardware-rooted certificate from which all of the above can be verified. As a result, Constellation wraps an entire cluster into one coherent *confidential context*. The concept is depicted in the following.
|
||||
## Constellation security features
|
||||
|
||||
Constellation implements the Confidential Kubernetes concept with the following security features.
|
||||
|
||||
* **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.)
|
||||
* **"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.
|
||||
|
||||

|
||||
|
||||
## Contrast: 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.
|
||||
|
||||

|
114
docs/versioned_docs/version-2.0/overview/performance.md
Normal file
@ -0,0 +1,114 @@
|
||||
# Performance
|
||||
|
||||
This section analyses the performance of Constellation.
|
||||
|
||||
## Performance impact from runtime encryption
|
||||
|
||||
All nodes in a Constellation cluster run inside Confidential VMs (CVMs). Thus, Constellation's performance is directly affected by the performance of CVMs.
|
||||
|
||||
AMD and Azure jointly released a [performance benchmark](https://community.amd.com/t5/business/microsoft-azure-confidential-computing-powered-by-3rd-gen-epyc/ba-p/497796) for CVMs based on 3rd Gen AMD EPYC processors (Milan) with SEV-SNP. With a range of mostly compute-intensive benchmarks like SPEC CPU 2017 and CoreMark, they found that CVMs only have a small (2%--8%) performance degradation compared to standard VMs. You can expect to see similar performance for compute-intensive workloads running on Constellation.
|
||||
|
||||
## Performance impact from other features
|
||||
|
||||
To assess the overall performance of Constellation, we benchmarked Constellation v1.3.0 using [K-Bench](https://github.com/vmware-tanzu/k-bench). K-Bench is a configurable framework to benchmark Kubernetes clusters in terms of storage I/O, network performance, and creating/scaling resources.
|
||||
|
||||
As a baseline, we compare Constellation with the non-confidential managed Kubernetes offerings on Microsoft Azure and Google Cloud Platform (GCP). These are AKS on Azure and GKE on GCP.
|
||||
|
||||
### Configurations
|
||||
|
||||
We used the following configurations for the benchmarks.
|
||||
|
||||
#### Constellation and GKE on GCP
|
||||
|
||||
- Nodes: 3
|
||||
- Machines: `n2d-standard-2`
|
||||
- Kubernetes version: `1.23.6-gke.2200`
|
||||
- Zone: `europe-west3-b`
|
||||
|
||||
#### Constellation and AKS on Azure
|
||||
|
||||
- Nodes: 3
|
||||
- Machines: `D2a_v4`
|
||||
- Kubernetes version: `1.23.5`
|
||||
- Region: `North Europe`
|
||||
- Zone: `2`
|
||||
|
||||
#### K-Bench
|
||||
|
||||
Using the default [K-Bench test configurations](https://github.com/vmware-tanzu/k-bench/tree/master/config), we ran the following tests on the clusters:
|
||||
|
||||
- `default`
|
||||
- `dp_netperf_internode`
|
||||
- `dp_network_internode`
|
||||
- `dp_network_intranode`
|
||||
- `dp_fio`
|
||||
|
||||
### Results
|
||||
|
||||
#### 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.
|
||||
|
||||
The three graphs below compare the API latencies (lower is better) in milliseconds for pods, services, and deployments.
|
||||
|
||||

|
||||
|
||||
Pods: Except for the `Pod Update` call, Constellation is faster than AKS and GKE in terms of API calls.
|
||||
|
||||

|
||||
|
||||
Services: Constellation has lower latencies than AKS and GKE except for service creation on AKS.
|
||||
|
||||

|
||||
|
||||
Deployments: Constellation has the lowest latency for all cases except for scaling deployments on GKE and creating deployments on AKS.
|
||||
|
||||
#### 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`.
|
||||
|
||||
##### Inter-node
|
||||
|
||||
K-Bench has two benchmarks to evaluate the network performance between different nodes.
|
||||
|
||||
The first test (`dp_netperf_internode`) uses [`netperf`](https://hewlettpackard.github.io/netperf/) to measure the throughput. Constellation has a slightly lower network throughput than AKS and GKE.
|
||||
This can largely be attributed to its [network encryption](../architecture/networking.md).
|
||||
|
||||
##### Intra-node
|
||||
|
||||
Intra-node communication happens between pods running on the same node.
|
||||
The connections directly pass through the node's OS layer and never hit the network.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
### Storage I/O
|
||||
|
||||
Azure and GCP offer persistent storage for their Kubernetes services AKS and GKE via the Container Storage Interface (CSI). CSI storage in Kubernetes is available via `PersistentVolumes` (PV) and consumed via `PersistentVolumeClaims` (PVC).
|
||||
Upon requesting persistent storage through a PVC, GKE and AKS will provision a PV as defined by a default [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/).
|
||||
Constellation provides persistent storage on Azure and GCP [that's encrypted on the CSI layer](../architecture/encrypted-storage.md).
|
||||
Similarly, Constellation will provision a PV via a default storage class upon a PVC request.
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
Comparing Constellation on GCP with GKE, we 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.
|
||||
|
||||
:::note
|
||||
For the sequential reads with a `0/100 read-write mix`, no data could be measured on AKS, hence the missing data bar.
|
||||
:::
|
||||
|
||||
## Conclusion
|
||||
|
||||
Despite providing substantial [security benefits](./security-benefits.md), Constellation overall only has a slight performance overhead over the managed Kubernetes offerings AKS and GKE. Constellation is on par in most benchmarks, but is slightly slower in certain scenarios due to network and storage encryption. When it comes to API latencies, Constellation even outperforms the less security-focused competition.
|
11
docs/versioned_docs/version-2.0/overview/product.md
Normal file
@ -0,0 +1,11 @@
|
||||
# Product features
|
||||
|
||||
Constellation is a Kubernetes engine that aims to provide the best possible data security in combination with enterprise-grade scalability and reliability features---and a smooth user experience.
|
||||
|
||||
From a security perspective, Constellation implements the [Confidential Kubernetes](confidential-kubernetes.md) concept and corresponding security features, which shield your entire cluster from the underlying infrastructure.
|
||||
|
||||
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.
|
||||
* **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.
|
@ -12,16 +12,17 @@ constellation [command]
|
||||
Commands:
|
||||
|
||||
* [config](#constellation-config): Work with the Constellation configuration file
|
||||
* [generate](#constellation-generate): Generate a default configuration file
|
||||
* [fetch-measurements](#constellation-fetch-measurements): Fetch measurements for configured cloud provider and image
|
||||
* [generate](#constellation-config-generate): Generate a default configuration file
|
||||
* [fetch-measurements](#constellation-config-fetch-measurements): Fetch measurements for configured cloud provider and image
|
||||
* [instance-types](#constellation-config-instance-types): Prints the supported instance types for all cloud providers
|
||||
* [create](#constellation-create): Create instances on a cloud platform for your Constellation cluster
|
||||
* [init](#constellation-init): Initialize the Constellation cluster
|
||||
* [verify](#constellation-verify): Verify the confidential properties of a Constellation cluster
|
||||
* [recover](#constellation-recover): Recover a completely stopped Constellation cluster
|
||||
* [terminate](#constellation-terminate): Terminate a Constellation cluster
|
||||
* [upgrade](#constellation-upgrade): Plan and perform an upgrade of a Constellation cluster
|
||||
* [execute](#constellation-execute): Execute an upgrade of a Constellation cluster
|
||||
* [plan](#constellation-plan): Plan an upgrade of a Constellation cluster
|
||||
* [execute](#constellation-upgrade-execute): Execute an upgrade of a Constellation cluster
|
||||
* [plan](#constellation-upgrade-plan): Plan an upgrade of a Constellation cluster
|
||||
* [version](#constellation-version): Display version of this CLI
|
||||
|
||||
## constellation config
|
||||
@ -95,6 +96,30 @@ constellation config fetch-measurements [flags]
|
||||
--config string path to the configuration file (default "constellation-conf.yaml")
|
||||
```
|
||||
|
||||
## constellation config instance-types
|
||||
|
||||
Prints the supported instance types for all cloud providers
|
||||
|
||||
### Synopsis
|
||||
|
||||
Prints the supported instance types for all cloud providers.
|
||||
|
||||
```
|
||||
constellation config instance-types [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for instance-types
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string path to the configuration file (default "constellation-conf.yaml")
|
||||
```
|
||||
|
||||
## constellation create
|
||||
|
||||
Create instances on a cloud platform for your Constellation cluster
|
||||
@ -104,7 +129,7 @@ Create instances on a cloud platform for your Constellation cluster
|
||||
Create instances on a cloud platform for your Constellation cluster.
|
||||
|
||||
```
|
||||
constellation create {aws|azure|gcp} [flags]
|
||||
constellation create [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
@ -112,7 +137,6 @@ constellation create {aws|azure|gcp} [flags]
|
||||
```
|
||||
-c, --control-plane-nodes int number of control-plane nodes (required)
|
||||
-h, --help help for create
|
||||
-t, --instance-type string instance type of cluster nodes
|
||||
--name string create the cluster with the specified name (default "constell")
|
||||
-w, --worker-nodes int number of worker nodes (required)
|
||||
-y, --yes create the cluster without further confirmation
|
||||
@ -162,7 +186,7 @@ Verify the confidential properties of a Constellation cluster.
|
||||
If arguments aren't specified, values are read from `constellation-id.json`.
|
||||
|
||||
```
|
||||
constellation verify {aws|azure|gcp} [flags]
|
||||
constellation verify [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
@ -196,7 +220,6 @@ constellation recover [flags]
|
||||
### Options
|
||||
|
||||
```
|
||||
--disk-uuid string disk UUID of the encrypted state disk (required)
|
||||
-e, --endpoint string endpoint of the instance, passed as HOST[:PORT] (required)
|
||||
-h, --help help for recover
|
||||
--master-secret string path to master secret file (default "constellation-mastersecret.json")
|
@ -67,17 +67,3 @@ kubernetesVersion: "1.24" # Kubernetes version installed in the cluster.
|
||||
# - username: Alice # Username of new SSH user.
|
||||
# publicKey: ssh-rsa AAAAB3NzaC...5QXHKW1rufgtJeSeJ8= alice@domain.com # Public key of new SSH user.
|
||||
```
|
||||
|
||||
## Required customizations
|
||||
|
||||
Most options of a generated configuration can be kept at their default values. However, you must edit some cloud provider options.
|
||||
|
||||
### Azure
|
||||
|
||||
Set the `subscription` and `tenant` IDs of your subscription.
|
||||
|
||||
Set the `userAssignedIdentity` that you [created for Constellation](../getting-started/install.md#azure).
|
||||
|
||||
### GCP
|
||||
|
||||
Set the `project` that you want to use for your Constellation cluster.
|
@ -25,7 +25,7 @@ You can find the currently supported machine types for your cloud environment in
|
||||
|
||||
Constellation can generate a configuration file for your cloud provider:
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
@ -56,23 +56,10 @@ For more details, see the [verification section](../workflows/verify.md).
|
||||
|
||||
The following command creates a cluster with one control-plane and two worker nodes:
|
||||
|
||||
<tabs>
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
constellation create azure --control-plane-nodes 1 --worker-nodes 2 --instance-type Standard_D4a_v4 -y
|
||||
constellation create --control-plane-nodes 1 --worker-nodes 2 -y
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
```bash
|
||||
constellation create gcp --control-plane-nodes 1 --worker-nodes 2 --instance-type n2d-standard-2 -y
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
For details on the flags and a list of supported instance types, consult the command help via `constellation create -h`.
|
||||
|
||||
*create* will store your cluster's configuration to a file named [`constellation-state.json`](../architecture/orchestration.md#installation-process) in your current directory.
|
@ -28,7 +28,7 @@ Constellation provides logging information on the boot process and status via [c
|
||||
In the following, you'll find detailed descriptions for identifying clusters stuck in recovery for each cloud environment.
|
||||
Once you've identified that your cluster is in an unhealthy state you can use the [recovery](recovery.md#recover-your-cluster) command of the Constellation CLI to restore it.
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
In the Azure cloud portal find the cluster's resource group `<cluster-name>-<suffix>`
|
||||
@ -44,26 +44,27 @@ In the serial console output search for `Waiting for decryption key`.
|
||||
Similar output to the following means your node was restarted and needs to decrypt the [state disk](../architecture/images.md#state-disk):
|
||||
|
||||
```shell
|
||||
{"level":"INFO","ts":"2022-08-01T08:02:20Z","caller":"cmd/main.go:46","msg":"Starting disk-mapper","version":"0.0.0","cloudProvider":"azure"}
|
||||
{"level":"INFO","ts":"2022-08-01T08:02:20Z","logger":"setupManager","caller":"setup/setup.go:57","msg":"Preparing existing state disk"}
|
||||
{"level":"INFO","ts":"2022-08-01T08:02:20Z","logger":"keyService","caller":"keyservice/keyservice.go:92","msg":"Waiting for decryption key. Listening on: [::]:9000"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:41Z","caller":"cmd/main.go:55","msg":"Starting disk-mapper","version":"2.0.0","cloudProvider":"azure"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"setupManager","caller":"setup/setup.go:72","msg":"Preparing existing state disk"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"recoveryServer","caller":"recoveryserver/server.go:59","msg":"Starting RecoveryServer"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"rejoinClient","caller":"rejoinclient/client.go:65","msg":"Starting RejoinClient"}
|
||||
```
|
||||
|
||||
The node will then try to connect to the [*JoinService*](../architecture/components.md#joinservice) and obtain the decryption key.
|
||||
If that fails, because the control plane is unhealthy, you will see log messages similar to the following:
|
||||
|
||||
```shell
|
||||
{"level":"INFO","ts":"2022-08-01T08:02:21Z","logger":"keyService","caller":"keyservice/keyservice.go:118","msg":"Received list with JoinService endpoints: [10.9.0.5:30090 10.9.0.6:30090 10.9.0.7:30090 10.9.0.8:30090 10.9.0.9:30090 10.9.0.10:30090 10.9.0.11:30090 10.9.0.12:30090 10.9.0.13:30090 10.9.0.14:30090 10.9.0.15:30090 10.9.0.16:30090 10.9.0.17:30090 10.9.0.18:30090 10.9.0.19:30090 10.9.0.20:30090 10.9.0.21:30090 10.9.0.22:30090 10.9.0.23:30090]"}
|
||||
{"level":"INFO","ts":"2022-08-01T08:02:21Z","logger":"keyService","caller":"keyservice/keyservice.go:145","msg":"Requesting rejoin ticket","endpoint":"10.9.0.5:30090"}
|
||||
{"level":"ERROR","ts":"2022-08-01T08:02:21Z","logger":"keyService","caller":"keyservice/keyservice.go:148","msg":"Failed to request rejoin ticket","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 10.9.0.5:30090: connect: connection refused\"","endpoint":"10.9.0.5:30090"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"rejoinClient","caller":"rejoinclient/client.go:77","msg":"Received list with JoinService endpoints","endpoints":["10.9.0.5:30090","10.9.0.6:30090"]}
|
||||
{"level":"INFO","ts":"2022-09-08T09:56:43Z","logger":"rejoinClient","caller":"rejoinclient/client.go:96","msg":"Requesting rejoin ticket","endpoint":"10.9.0.5:30090"}
|
||||
{"level":"WARN","ts":"2022-09-08T09:57:03Z","logger":"rejoinClient","caller":"rejoinclient/client.go:101","msg":"Failed to rejoin on endpoint","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 10.9.0.5:30090: i/o timeout\"","endpoint":"10.9.0.5:30090"}
|
||||
{"level":"INFO","ts":"2022-09-08T09:57:03Z","logger":"rejoinClient","caller":"rejoinclient/client.go:96","msg":"Requesting rejoin ticket","endpoint":"10.9.0.6:30090"}
|
||||
{"level":"WARN","ts":"2022-09-08T09:57:23Z","logger":"rejoinClient","caller":"rejoinclient/client.go:101","msg":"Failed to rejoin on endpoint","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 10.9.0.6:30090: i/o timeout\"","endpoint":"10.9.0.6:30090"}
|
||||
{"level":"ERROR","ts":"2022-09-08T09:57:23Z","logger":"rejoinClient","caller":"rejoinclient/client.go:110","msg":"Failed to rejoin on all endpoints"}
|
||||
```
|
||||
|
||||
That means you have to recover that node manually.
|
||||
Before you continue with the [recovery process](#recover-your-cluster) you need to know the node's IP address and state disk's UUID.
|
||||
Before you continue with the [recovery process](#recover-your-cluster) you need to know the node's IP address.
|
||||
For the IP address, return to the instances *Overview* page and find the *Private IP address*.
|
||||
For the UUID open the [Cloud logging](troubleshooting.md#azure) explorer.
|
||||
Type `traces | where message contains "Disk UUID"` and click `Run`.
|
||||
Find the entry corresponding to that instance `{"instance-name":"<cluster-name>-control-plane-<suffix>"}` and take the UUID from the message field `Disk UUID: <UUID>`.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
@ -81,25 +82,28 @@ In the serial console output search for `Waiting for decryption key`.
|
||||
Similar output to the following means your node was restarted and needs to decrypt the [state disk](../architecture/images.md#state-disk):
|
||||
|
||||
```shell
|
||||
{"level":"INFO","ts":"2022-07-29T09:45:55Z","caller":"cmd/main.go:46","msg":"Starting disk-mapper","version":"0.0.0","cloudProvider":"gcp"}
|
||||
{"level":"INFO","ts":"2022-07-29T09:45:55Z","logger":"setupManager","caller":"setup/setup.go:57","msg":"Preparing existing state disk"}
|
||||
{"level":"INFO","ts":"2022-07-29T09:45:55Z","logger":"keyService","caller":"keyservice/keyservice.go:92","msg":"Waiting for decryption key. Listening on: [::]:9000"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","caller":"cmd/main.go:55","msg":"Starting disk-mapper","version":"2.0.0","cloudProvider":"gcp"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"setupManager","caller":"setup/setup.go:72","msg":"Preparing existing state disk"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"rejoinClient","caller":"rejoinclient/client.go:65","msg":"Starting RejoinClient"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"recoveryServer","caller":"recoveryserver/server.go:59","msg":"Starting RecoveryServer"}
|
||||
|
||||
```
|
||||
|
||||
The node will then try to connect to the [*JoinService*](../architecture/components.md#joinservice) and obtain the decryption key.
|
||||
If that fails, because the control plane is unhealthy, you will see log messages similar to the following:
|
||||
|
||||
```shell
|
||||
{"level":"INFO","ts":"2022-07-29T09:46:15Z","logger":"keyService","caller":"keyservice/keyservice.go:118","msg":"Received list with JoinService endpoints: [192.168.178.2:30090]"}
|
||||
{"level":"INFO","ts":"2022-07-29T09:46:15Z","logger":"keyService","caller":"keyservice/keyservice.go:145","msg":"Requesting rejoin ticket","endpoint":"192.168.178.2:30090"}
|
||||
{"level":"ERROR","ts":"2022-07-29T09:46:15Z","logger":"keyService","caller":"keyservice/keyservice.go:148","msg":"Failed to request rejoin ticket","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 192.168.178.2:30090: connect: connection refused\"","endpoint":"192.168.178.2:30090"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"rejoinClient","caller":"rejoinclient/client.go:77","msg":"Received list with JoinService endpoints","endpoints":["192.168.178.4:30090","192.168.178.2:30090"]}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"rejoinClient","caller":"rejoinclient/client.go:96","msg":"Requesting rejoin ticket","endpoint":"192.168.178.4:30090"}
|
||||
{"level":"WARN","ts":"2022-09-08T10:21:53Z","logger":"rejoinClient","caller":"rejoinclient/client.go:101","msg":"Failed to rejoin on endpoint","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 192.168.178.4:30090: connect: connection refused\"","endpoint":"192.168.178.4:30090"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:21:53Z","logger":"rejoinClient","caller":"rejoinclient/client.go:96","msg":"Requesting rejoin ticket","endpoint":"192.168.178.2:30090"}
|
||||
{"level":"WARN","ts":"2022-09-08T10:22:13Z","logger":"rejoinClient","caller":"rejoinclient/client.go:101","msg":"Failed to rejoin on endpoint","error":"rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 192.168.178.2:30090: i/o timeout\"","endpoint":"192.168.178.2:30090"}
|
||||
{"level":"ERROR","ts":"2022-09-08T10:22:13Z","logger":"rejoinClient","caller":"rejoinclient/client.go:110","msg":"Failed to rejoin on all endpoints"}
|
||||
```
|
||||
|
||||
That means you have to recover that node manually.
|
||||
Before you continue with the [recovery process](#recover-your-cluster) you need to know the node's IP address and state disk's UUID.
|
||||
Before you continue with the [recovery process](#recover-your-cluster) you need to know the node's IP address.
|
||||
For the IP address go to the *"VM Instance" -> "network interfaces"* page and take the address from *"Primary internal IP address."*
|
||||
For the UUID open the [Cloud logging](troubleshooting.md#cloud-logging) explorer, you'll find that right above the serial console link (see the picture above).
|
||||
Search for `Disk UUID: <UUID>`.
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
@ -114,10 +118,9 @@ From there, your cluster will auto heal the remaining 2 control-plane nodes and
|
||||
Recovering a node requires the following parameters:
|
||||
|
||||
* The node's IP address
|
||||
* The node's state disk UUID
|
||||
* Access to the master secret of the cluster
|
||||
|
||||
See the [Identify unhealthy clusters](#identify-unhealthy-clusters) description of how to obtain the node's IP address and state disk UUID.
|
||||
See the [Identify unhealthy clusters](#identify-unhealthy-clusters) description of how to obtain the node's IP address.
|
||||
Note that the recovery command needs to connect to the recovering nodes.
|
||||
Nodes only have private IP addresses in the VPC of the cluster, hence, the command needs to be issued from within the VPC network of the cluster.
|
||||
The easiest approach is to set up a jump host connected to the VPC network and perform the recovery from there.
|
||||
@ -125,23 +128,17 @@ The easiest approach is to set up a jump host connected to the VPC network and p
|
||||
Given these prerequisites a node can be recovered like this:
|
||||
|
||||
```bash
|
||||
$ constellation recover -e 34.107.89.208 --disk-uuid b27f817c-6799-4c0d-81d8-57abc8386b70 --master-secret constellation-mastersecret.json
|
||||
$ constellation recover -e 34.107.89.208 --master-secret constellation-mastersecret.json
|
||||
Pushed recovery key.
|
||||
```
|
||||
|
||||
In the serial console output of the node you'll see a similar output to the following:
|
||||
|
||||
```shell
|
||||
[ 3225.621753] EXT4-fs (dm-1): INFO: recovery required on readonly filesystem
|
||||
[ 3225.628807] EXT4-fs (dm-1): write access will be enabled during recovery
|
||||
[ 3226.295816] EXT4-fs (dm-1): recovery complete
|
||||
[ 3226.301618] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
|
||||
[ 3226.338157] systemd[1]: run-state.mount: Deactivated successfully.
|
||||
[[0;32m OK [[ 3226.347833] systemd[1]: Finished Prepare encrypted state disk.
|
||||
0m] Finished [0;1;39mPrepare encrypted state disk[0m.
|
||||
Startin[ 3226.363705] systemd[1]: Starting OSTree Prepare OS/...
|
||||
g [0;1;39mOSTre[ 3226.370625] ostree-prepare-root[939]: preparing sysroot at /sysroot
|
||||
e Prepare OS/[0m...
|
||||
{"level":"INFO","ts":"2022-09-08T10:26:59Z","logger":"recoveryServer","caller":"recoveryserver/server.go:93","msg":"Received recover call"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:26:59Z","logger":"recoveryServer","caller":"recoveryserver/server.go:125","msg":"Received state disk key and measurement secret, shutting down server"}
|
||||
{"level":"INFO","ts":"2022-09-08T10:26:59Z","logger":"recoveryServer.gRPC","caller":"zap/server_interceptors.go:61","msg":"finished streaming call with code OK","grpc.start_time":"2022-09-08T10:26:59Z","system":"grpc","span.kind":"server","grpc.service":"recoverproto.API","grpc.method":"Recover","peer.address":"192.0.2.3:41752","grpc.code":"OK","grpc.time_ms":15.701}
|
||||
{"level":"INFO","ts":"2022-09-08T10:27:13Z","logger":"rejoinClient","caller":"rejoinclient/client.go:87","msg":"RejoinClient stopped"}
|
||||
```
|
||||
|
||||
After enough control plane nodes have been recovered and the Kubernetes cluster becomes healthy again, the rest of the cluster will start auto healing using the mechanism described above.
|
@ -8,7 +8,7 @@ Constellation provides all features of a Kubernetes cluster including scaling an
|
||||
|
||||
Alternatively, you can choose to manually scale your cluster:
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
1. Find your Constellation resource group.
|
||||
@ -34,7 +34,7 @@ Control-plane nodes can **only be scaled manually and only scaled up**!
|
||||
|
||||
To increase the number of control-plane nodes, follow these steps:
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
@ -22,7 +22,7 @@ For more details see [encrypted persistent storage](../architecture/encrypted-st
|
||||
|
||||
Constellation can use the following drivers which offer node level encryption and optional integrity protection.
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
1. [Azure Disk Storage](https://github.com/edgelesssys/constellation-azuredisk-csi-driver)
|
||||
@ -48,7 +48,7 @@ Note that in case the options above aren't a suitable solution for you, Constell
|
||||
|
||||
The following installation guide gives a brief overview of using CSI-based confidential cloud storage for persistent volumes in Constellation.
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
1. Install the CSI driver:
|
||||
@ -184,7 +184,7 @@ By default, integrity protection is disabled for performance reasons. If you wan
|
||||
### Set the default storage class
|
||||
The examples above are defined to be automatically set as the default storage class. The default storage class is responsible for all persistent volume claims that don't explicitly request `storageClassName`. In case you need to change the default, follow the steps below:
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
1. List the storage classes in your cluster:
|
@ -8,7 +8,7 @@ To provide information during early stages of the node's boot process, Constella
|
||||
|
||||
You can view these information in the follow places:
|
||||
|
||||
<tabs>
|
||||
<tabs groupId="csp">
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
1. In your Azure subscription find the Constellation resource group.
|
45
docs/versioned_docs/version-2.0/workflows/trusted-launch.md
Normal file
@ -0,0 +1,45 @@
|
||||
# Azure trusted launch VMs
|
||||
|
||||
Constellation supports Azure trusted launch VMs. These are VMs with instance type `Standard_D*_v4` and `Standard_E*_v4`.
|
||||
|
||||
:::caution
|
||||
|
||||
Trusted launch VMs don't provide [runtime encryption](../overview/confidential-kubernetes.md).
|
||||
For highest security, use Confidential VMs.
|
||||
|
||||
:::
|
||||
|
||||
Run `constellation config instance-types` to show all supported instance types.
|
||||
|
||||
## VM images
|
||||
|
||||
Azure currently doesn't support [community galleries for trusted launch VMs](https://docs.microsoft.com/en-us/azure/virtual-machines/share-gallery-community). So you need to import the VM image into your cloud subscription.
|
||||
|
||||
The latest image is available at [https://public-edgeless-constellation.s3.us-east-2.amazonaws.com/azure_image_exports/2.0.0](https://public-edgeless-constellation.s3.us-east-2.amazonaws.com/azure_image_exports/2.0.0). Simply adjust the last three numbers if you want to download an image for a different version.
|
||||
|
||||
After you've downloaded the image, create a resource group `constellation-images` in your Azure subscription and import the image.
|
||||
You can use a script to do this:
|
||||
```bash
|
||||
wget https://github.com/edgelesssys/constellation/blob/main/hack/importAzure.sh
|
||||
chmod +x importAzure.sh
|
||||
AZURE_IMAGE_VERSION=2.0.0 AZURE_RESOURCE_GROUP_NAME=constellation-images AZURE_IMAGE_FILE=./2.0.0 ./importAzure.sh
|
||||
```
|
||||
|
||||
The script creates the following resources:
|
||||
1. A new image gallery with the default name `constellation-import`
|
||||
2. A new image definition with the default name `constellation`
|
||||
3. The actual image with the provided version. In this case `2.0.0`
|
||||
|
||||
Once the import is completed, use the `ID` of the image version in your `constellation-conf.yaml` for the `image` field. Set `confidentialVM` to `false`.
|
||||
|
||||
:::info
|
||||
|
||||
The [constellation create](create.md) command will issue a warning because manually imported images aren't recognized as production grade images:
|
||||
|
||||
```shell-session
|
||||
Configured image doesn't look like a released production image. Double check image before deploying to production.
|
||||
```
|
||||
|
||||
Please ignore this warning.
|
||||
|
||||
:::
|
@ -22,23 +22,10 @@ Once measurements are configured, this command verifies an attestation statement
|
||||
|
||||
The following command performs attestation on the Constellation in your current workspace:
|
||||
|
||||
<tabs>
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
constellation verify azure
|
||||
constellation verify
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
```bash
|
||||
constellation verify gcp
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
The command makes sure the value passed to `-cluster-id` matches the *clusterID* presented in the attestation statement.
|
||||
This allows you to verify that you are connecting to a specific Constellation instance
|
||||
Additionally, the confidential computing capabilities, as well as the VM image, are verified to match the expected configurations.
|
||||
@ -50,19 +37,6 @@ You can provide additional arguments for `verify` to verify any Constellation yo
|
||||
* The IP address of a running Constellation's [VerificationService](../architecture/components.md#verification-service). The *VerificationService* is exposed via a NodePort service using the external IP address of your cluster. Run `kubectl get nodes -o wide` and look for `EXTERNAL-IP`.
|
||||
* The Constellation's *clusterID*. See [cluster identity](../architecture/keys.md#cluster-identity) for more details.
|
||||
|
||||
<tabs>
|
||||
<tabItem value="azure" label="Azure" default>
|
||||
|
||||
```bash
|
||||
constellation verify azure -e 192.0.2.1 --cluster-id Q29uc3RlbGxhdGlvbkRvY3VtZW50YXRpb25TZWNyZXQ=
|
||||
constellation verify -e 192.0.2.1 --cluster-id Q29uc3RlbGxhdGlvbkRvY3VtZW50YXRpb25TZWNyZXQ=
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP" default>
|
||||
|
||||
```bash
|
||||
constellation verify gcp -e 192.0.2.1 --cluster-id Q29uc3RlbGxhdGlvbkRvY3VtZW50YXRpb25TZWNyZXQ=
|
||||
```
|
||||
|
||||
</tabItem>
|
||||
</tabs>
|
@ -2,12 +2,12 @@
|
||||
"docs": [
|
||||
{
|
||||
"type": "doc",
|
||||
"label": "Welcome to Constellation",
|
||||
"label": "Introduction",
|
||||
"id": "intro"
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Overview",
|
||||
"label": "Basics",
|
||||
"link": {
|
||||
"type": "generated-index"
|
||||
},
|
||||
@ -27,10 +27,15 @@
|
||||
"label": "Product features",
|
||||
"id": "overview/product"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"label": "Feature status of clouds",
|
||||
"id": "overview/clouds"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"label": "Performance",
|
||||
"id": "overview/benchmarks"
|
||||
"id": "overview/performance"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
@ -115,6 +120,11 @@
|
||||
"label": "Use persistent storage",
|
||||
"id": "workflows/storage"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"label": "Azure trusted launch VMs",
|
||||
"id": "workflows/trusted-launch"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"label": "Managing SSH keys",
|
@ -1,3 +1,3 @@
|
||||
[
|
||||
"1.5"
|
||||
"2.0"
|
||||
]
|
||||
|