AMD SEV-SNP

Requirements

• Helm v3

• Kubernetes (Kubelet, Kubectl, Kubeadm)

• a container runtime

• Docker Installation for Ubuntu (for building and pushing the images)

  • Add current user to docker group, if you haven't already: sudo usermod -aG docker $USER and logout and login again from your OS. Now login to docker.

• Vault-CLI

• install make and jq

• A confidential VM (protected by SEV or TDX).

  • All steps have to be done inside a confidential VM

  • Security depends on the fact, that the control plane is inside a confidential VM

You do not need a domain for this example, but of course you can use one!

Preparation

1.1

Initialise a Kubernetes cluster and install a networking plugin of your choice. Here is an example using Calico (skip to #2.1 if you want to install a different networking plugin, but do 1.2 first)

1.2

Initialize your cluster. The pod-network-cidr is required by calico.

sudo kubeadm init --pod-network-cidr=192.168.0.0/16 

1.3

let the current user, use the kubeconfig:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Not recommended in production:

If you only have one node in your cluster, you need to use the control plane node to schedule pods on. Done by executing :

kubectl taint nodes --all  node-role.kubernetes.io/control-plane-

1.4

Clone the repository

git clone https://github.com/enclaive/morphism.git

Navigate to

cd ./morphism/deployments/azure_dca

Set-up

This example uses the 'sed' command to replace some values. Meaning that, you have to pull the repository again, if you want to change any parameters you specified or manually change them.

2.1

The Makefile expects your shell to be in the same folder, otherwise some commands won't work. Add the required helm repos with:

make add-helm-repos

2.2

Now for a quick-start you can issue the command below and replace the parameters to fit your environment. It sums up the below make commands to 2.5 in a single command.

make quick-start ip=your_ip cert_manager=false load_balancer=true auto_tls=false domain=example.com development=true

Read the FAQ to understand, the parameters do. Some Helm Charts take some time to install. Do not cancel them! If it takes over 2 Minutes, then something was configured wrong.

cert_manager must be set to true for auto_tls to work.

2.3

First, set the vault address environment variable for the vault-cli to know vault's address.

export VAULT_ADDR="https://vault.{{yourdomain.com}}"

Also, use to set the created certificate as trusted (this can also be done by copying the certificate to your OS's truststore):

 export VAULT_CACERT="./examples/certs/cert.pem"

2.4

Initialize the vault and receive the unseal key + the admin token. See #dns-wildcard-entry if you do not have a domain, and want to add a wildcard DNS entry or add vault.{{yourdomain.com}} to your /etc/hosts file to map the IP address of the load balancer

vault operator init -key-shares=1 -key-threshold=1

Note that, it is important to keep both values confidential in production and have to be stored securely. Unseal the vault by providing the unseal key.

vault operator unseal

Login to the vault by providing the token.

vault login

2.5

Almost done! Provide here a secret message, which should be displayed in the example. This secret gets saved in to the vault's key value store.

make configure-vault message={{your secret message}}

2.6

Lastly, deploy the example. For this to work, you have to push the image to a public image repository. A private one also works, but the Knative Service yaml files then have to include the imagePullSecret. Furthermore, this example assumes that the docker-cli is used, to push the image to the repository. To do this, you must be logged in to your docker account with the docker-cli.

The next command will build and then push the image. Also, userpass is used as the vault authentication method and the user account is created here. Specify any username and password you want. For actix use:

make actix image_name=username/image_name username=user password=password
make flask image_name=username/image_name username=user password=password

Now, you are able to see your secret message by calling:

 curl actix.default.{{your-domain.com}}/read_secret
 curl flask.default.{{your-domain.com}}/read-secret

That's it, have fun with Serverless Confidential Containers

FAQ

How does the Vault receive it's certificate?

For https Vault requires a certificate and a private key. You can either use your own certificate and private key, if you want, or generate it with the next make command. With the latter, however, the following must be taken into account. The pre-main binary calls the vault with vault.vault.svc.cluster.local, and must either be changed in the main.go or included in the subject alternative name extension of your certificate. Moreover, also vault.{{your-domain.com}} should be included in the certificate.

The certificates will be saved at ./examples/certs/ where the Vault and the examples expects them to be. The filenames should be cert.pem and key.pem. If you use your own certificate, the hostPath in the yaml of the vault found at ./sev-csc-demo/templates/vault.yaml has to be set. For the vault to be able to read the private key, the permissions have to be adjusted. Lastly, these certificates are included into the docker file examples and added to their trust store.