AMD SEV-SNP

Requirements

circle-info

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 AMD SEV-SNP 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.

1.3

let the current user, use the kubeconfig:

circle-info

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 :

1.4

Clone the repository

Navigate to

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:

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.

circle-info

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.

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

2.4

Initialize the vault and receive the unseal key + the admin token. See AMD SEV-SNP 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

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.

Login to the vault by providing the token.

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.

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:

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

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.

Last updated