Reorganize Quickstart Guide

Simplify quickstart guide to cover installation,
basic usage, encryption/signing, attestation.
Focus on the generic KBS.
Everything else is moved to other files. Pointers
to the relevant files are included where needed.

Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>

guides/enclave-cc.md

@@ -0,0 +1,97 @@
+# Enclave-CC
+
+`enclave-cc` provides process-based isolation using SGX.
+This guide assumes that you already have a Kubernetes cluster
+and have deployed the operator as described in the **Installation**
+section of the [quickstart guide](../quickstart.md).
+
+## Configuring enclave-cc custom resource to use a different KBC
+
+**Note** The KBC configuration changes to the enclave-cc custom resource yaml 
+must be made **before** deploying it. 
+
+Enclave CC supports Verdictd and in order to use it, users will have to
+properly configure a decrypt_config.conf, in order to set the `KBC` (`sample_kbc`
+or `eaa_kbc`) `IP`,`PORT`, and the `SECURITY_VALIDATE` (`false` or  `true`)
+```
+{
+    "key_provider": "provider:attestation-agent:KBC::IP:PORT",
+     "security_validate": SECURITY_VALIDATE
+}
+```
+
+Once that's set according to the users needs, the user will then have to run:
+`cat decrypt_config.conf | base64 -w 0` in order to get the data encoded and
+set it accordingly [here](https://github.com/confidential-containers/operator/blob/6f241fbc056f0a5d9e1bd2c10b2cedc0782b99ff/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml#L124).
+
+## Creating a sample CoCo workload using enclave-cc
+
+As an example, we setup a sample *hello world*
+workload with an encrypted and cosign signed container image using the `enclave-cc` runtime class for process based TEEs.
+The deployment below assumes the hardware SGX mode build is installed by the operator. To try on a non-TEE system, please
+use simulate SGX mode build.
+
+The example uses a trivial hello world C application:
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  name: enclave-cc-pod
+spec:
+  containers:
+  - image: ghcr.io/confidential-containers/test-container-enclave-cc:encrypted
+    name: hello-world
+    workingDir: "/run/rune/boot_instance/"
+    resources:
+      limits:
+        sgx.intel.com/epc: 600Mi
+    env:
+    - name: OCCLUM_RELEASE_ENCLAVE
+      value: "1"
+    command:
+    - /run/rune/boot_instance/build/bin/occlum-run
+    - /bin/hello_world
+  runtimeClassName: enclave-cc
+
+```
+
+**Note** When the hardware SGX mode payload is used in an SGX enabled cluster, `sgx.intel.com/epc: 600Mi`
+resource request must be added to the pod spec.
+
+Again, create a pod YAML file as previously described (this time we named it `enclave-cc-pod.yaml`) .
+
+Create the workload:
+```
+kubectl apply -f enclave-cc-pod.yaml
+```
+Output:
+```
+pod/enclave-cc-pod created
+```
+
+Ensure the pod was created successfully (in running state):
+```
+kubectl get pods
+```
+Output:
+```
+NAME                 READY   STATUS    RESTARTS   AGE
+enclave-cc-pod   1/1     Running   0          22s
+```
+
+Check the pod is running as expected:
+```
+kubectl logs enclave-cc-pod | head -5
+```
+Output:
+```
+["init"]
+Hello world!
+
+Hello world!
+
+```
+
+We can also verify the host does not have the image for others to use:
+```
+crictl -r unix:///run/containerd/containerd.sock image ls | grep helloworld_enc

guides/ephemeral_storage.md

@@ -0,0 +1,97 @@
+# Trusted Ephemeral Storage for container images
+
+With CoCo, container images are pulled inside the guest VM.
+By default container images are saved in guest memory which is protected by CC hardware.
+Since memory is an expensive resource, CoCo implemented [trusted ephemeral storage](https://github.com/confidential-containers/documentation/issues/39) for container image and RW layer.
+
+This solution is verified with Kubernetes CSI driver [open-local](https://github.com/alibaba/open-local). Please follow this [user guide](https://github.com/alibaba/open-local/blob/main/docs/user-guide/user-guide.md) to install open-local.
+
+We can use following example `trusted_store_cc.yaml` to have a try:
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  name: trusted-lvm-block
+spec:
+  runtimeClassName: kata-qemu-tdx
+  containers:
+   - name: sidecar-trusted-store
+     image: pause
+     volumeDevices:
+     - devicePath: "/dev/trusted_store"
+       name: trusted-store
+   - name: application
+     image: busybox
+     command:
+     - sh
+     - "-c"
+     - |
+         sleep 10000
+  volumes:
+   - name: trusted-store
+     persistentVolumeClaim:
+       claimName: trusted-store-block-pvc
+---
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: trusted-store-block-pvc
+spec:
+  volumeMode: Block
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+  storageClassName: open-local-lvm
+```
+Before deploy the workload, we can follow this [documentation](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/how-to-build-and-test-ccv0.md) and use [ccv0.sh](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/ccv0.sh) to enable CoCo console debug(optional, check whether working as expected).
+
+Create the workload:
+```
+kubectl apply -f trusted_store_cc.yaml
+```
+
+Ensure the pod was created successfully (in running state):
+```
+kubectl get pods
+```
+
+Output:
+```
+NAME                READY   STATUS    RESTARTS   AGE
+trusted-lvm-block   2/2     Running   0          31s
+```
+
+After we enable the debug option, we can login into the VM with `ccv0.sh` script:
+```
+./ccv0.sh -d open_kata_shell
+```
+
+Check container image is saved in encrypted storage with following commands:
+```
+root@localhost:/# lsblk --fs
+NAME                             FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
+sda
+└─ephemeral_image_encrypted_disk                      906M     0% /run/image
+
+root@localhost:/# cryptsetup status ephemeral_image_encrypted_disk
+/dev/mapper/ephemeral_image_encrypted_disk is active and is in use.
+  type:    LUKS2
+  cipher:  aes-xts-plain64
+  keysize: 512 bits
+  key location: dm-crypt
+  device:  /dev/sda
+  sector size:  4096
+  offset:  32768 sectors
+  size:    2064384 sectors
+  mode:    read/write
+
+root@localhost:/# mount|grep image
+/dev/mapper/ephemeral_image_encrypted_disk on /run/image type ext4 (rw,relatime)
+
+root@localhost:/# ls /run/image/
+layers  lost+found  overlay
+```
+
+

guides/nontee_demo.md

@@ -0,0 +1,90 @@
+# Encrypted Container Images without Hardware Support
+
+Without Confidential Computing hardware, there is no way to securely provision
+the keys for an encrypted image. Nonetheless, in this demo we describe how to
+test encrypted images suppot with the nontee `kata`/`kata-qemu` runtimeclass.
+
+## Creating a CoCo workload using a pre-existing encrypted image
+
+We will now proceed to download and run a sample encrypted container image using the CoCo building blocks.
+
+A demo container image is provided at [docker.io/katadocker/ccv0-ssh](https://hub.docker.com/r/katadocker/ccv0-ssh).
+It is encrypted with [Attestation Agent](https://github.com/confidential-containers/attestation-agent)'s [offline file system key broker](https://github.com/confidential-containers/attestation-agent/tree/64c12fbecfe90ba974d5fe4896bf997308df298d/src/kbc_modules/offline_fs_kbc) and [`aa-offline_fs_kbc-keys.json`](https://github.com/confidential-containers/documentation/blob/main/demos/ssh-demo/aa-offline_fs_kbc-keys.json) as its key file.
+
+We have prepared a sample CoCo operator custom resource that is based on the standard `ccruntime.yaml`, but in addition has the the decryption keys and configuration required to decrypt this sample container image.
+> **Note** All pods started with this sample resource will be able to decrypt the sample container and all keys shown are for demo purposes only and should not be used in production.
+
+ To test out creating a workload from the sample encrypted container image, we can take the following steps:
+
+### Swap out the standard custom resource for our sample
+
+Support for multiple custom resources in not available in the current release. Consequently, if a custom resource already exists, then you'll need to remove it first before deploying a new one. We can remove the standard custom resource with:
+```
+kubectl delete -k github.com/confidential-containers/operator/config/samples/ccruntime/<CCRUNTIME_OVERLAY>?ref=<RELEASE_VERSION>
+```
+and in it's place install the modified version with the sample container's decryption key:
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/ccruntime/ssh-demo?ref=<RELEASE_VERSION>
+```
+Wait until each pod has the STATUS of Running.
+```
+kubectl get pods -n confidential-containers-system --watch
+```
+### Test creating a workload from the sample encrypted image
+
+Create a new Kubernetes deployment that uses the `docker.io/katadocker/ccv0-ssh` container image with:
+```
+cat << EOF > ccv0-ssh-demo.yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: ccv0-ssh
+spec:
+  selector:
+    app: ccv0-ssh
+  ports:
+  - port: 22
+---
+kind: Deployment
+apiVersion: apps/v1
+metadata:
+  name: ccv0-ssh
+spec:
+  selector:
+    matchLabels:
+      app: ccv0-ssh
+  template:
+    metadata:
+      labels:
+        app: ccv0-ssh
+    spec:
+      runtimeClassName: kata
+      containers:
+      - name: ccv0-ssh
+        image: docker.io/katadocker/ccv0-ssh
+        imagePullPolicy: Always
+EOF
+```
+
+Apply this with:
+```
+kubectl apply -f ccv0-ssh-demo.yaml
+```
+and waiting for the pod to start. This process should show that we are able to pull the encrypted image and using the decryption key configured in the CoCo sample guest image decrypt the container image and create a workload using it.
+
+The demo image has an SSH host key embedded in it, which is protected by it's encryption, but we can download the sample private key and use this to ssh into the container and validate the host key to ensure that it hasn't been tampered with.
+
+Download the SSH key with:
+```
+curl -Lo ccv0-ssh https://raw.githubusercontent.com/confidential-containers/documentation/main/demos/ssh-demo/ccv0-ssh
+```
+Ensure that the permissions are set correctly with:
+```
+chmod 600 ccv0-ssh
+```
+
+We can then use the key to ssh into the container:
+```
+$ ssh -i ccv0-ssh root@$(kubectl get service ccv0-ssh -o jsonpath="{.spec.clusterIP}")
+```
+You will be prompted about whether the host key fingerprint is correct. This fingerprint should match the one specified in the container image: `wK7uOpqpYQczcgV00fGCh+X97sJL3f6G1Ku4rvlwtR0.`