docs: add getting-started guide

Platform-specific setup will be added separately.

Sample workload guide will be simplified with tabbed codeboxes.

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

content/en/docs/getting-started/_index.md

@@ -4,4 +4,7 @@ description: High level overview of Confidential Containers
 weight: 20
 ---
 
-TODO
+This section will describe hardware and software prerequisites,
+installing Confidential Containers with an operator,
+verifying the installation,
+and running a pod with Confidential Containers.

content/en/docs/getting-started/installation.md

@@ -0,0 +1,120 @@
+---
+title: Installation 
+description: Installing Confidential Containers with the operator 
+weight: 20
+categories:
+- getting-started 
+tags:
+- operator
+- installation
+---
+
+### Deploy the operator
+
+Deploy the operator by running the following command  where `<RELEASE_VERSION>` needs to be substituted
+with the desired [release tag](https://github.com/confidential-containers/operator/tags).
+
+```
+kubectl apply -k github.com/confidential-containers/operator/config/release?ref=<RELEASE_VERSION>
+```
+
+For example, to deploy the `v0.10.0` release run:
+```
+kubectl apply -k github.com/confidential-containers/operator/config/release?ref=v0.10.0
+```
+
+Wait until each pod has the STATUS of Running.
+
+```
+kubectl get pods -n confidential-containers-system --watch
+```
+
+### Create the custom resource
+
+#### Create custom resource for kata
+
+Creating a custom resource installs the required CC runtime pieces into the cluster node and creates
+the `RuntimeClasses`
+
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/ccruntime/<CCRUNTIME_OVERLAY>?ref=<RELEASE_VERSION>
+```
+
+The current present overlays are: `default` and `s390x`
+
+For example, to deploy the `v0.10.0` release for `x86_64`, run:
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/ccruntime/default?ref=v0.10.0
+```
+
+And to deploy `v0.10.0` release for `s390x`, run:
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/ccruntime/s390x?ref=v0.10.0
+```
+
+Wait until each pod has the STATUS of Running.
+
+```
+kubectl get pods -n confidential-containers-system --watch
+```
+
+#### Create custom resource for enclave-cc
+
+**Note** For `enclave-cc` certain configuration changes, such as setting the
+URI of the KBS, must be made **before** applying the custom resource. 
+Please refer to the [guide](./guides/enclave-cc.md#configuring-enclave-cc-custom-resource-to-use-a-different-kbc)
+to modify the enclave-cc configuration.
+
+Please see the [enclave-cc guide](./guides/enclave-cc.md) for more information.
+
+`enclave-cc` is a form of Confidential Containers that uses process-based isolation.
+`enclave-cc` can be installed with the following custom resources.
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/enclave-cc/sim?ref=<RELEASE_VERSION>
+```
+or
+```
+kubectl apply -k github.com/confidential-containers/operator/config/samples/enclave-cc/hw?ref=<RELEASE_VERSION>
+```
+for the **simulated** SGX mode build or **hardware** SGX mode build, respectively.
+
+### Verify Installation
+
+Check the `RuntimeClasses` that got created.
+
+```
+kubectl get runtimeclass
+```
+Output:
+```
+NAME                 HANDLER              AGE
+kata                 kata-qemu            8d
+kata-clh             kata-clh             8d
+kata-qemu            kata-qemu            8d
+kata-qemu-coco-dev   kata-qemu-coco-dev   8d
+kata-qemu-sev        kata-qemu-sev        8d
+kata-qemu-snp        kata-qemu-snp        8d
+kata-qemu-tdx        kata-qemu-tdx        8d
+```
+
+Details on each of the runtime classes:
+
+- `kata` - Convenience runtime that uses the handler of the default runtime
+- `kata-clh` - standard kata runtime using the cloud hypervisor
+- `kata-qemu` - same as kata
+- `kata-qemu-coco-dev` - standard kata runtime using the QEMU hypervisor including all CoCo building blocks for a non CC HW
+- `kata-qemu-sev` - using QEMU, and support for AMD SEV HW
+- `kata-qemu-snp` - using QEMU, and support for AMD SNP HW
+- `kata-qemu-tdx` - using QEMU, and support Intel TDX HW based on what's provided by [Ubuntu](https://github.com/canonical/tdx) and [CentOS 9 Stream](https://sigs.centos.org/virt/tdx/).
+
+
+If you are using `enclave-cc` you should see the following runtime classes.
+
+```
+kubectl get runtimeclass
+```
+Output:
+```
+NAME            HANDLER         AGE
+enclave-cc      enclave-cc      9m55s
+```

content/en/docs/getting-started/prerequisites/_index.md

@@ -0,0 +1,10 @@
+---
+title: Prerequisites
+description: Requirements for deploying Confidential Containers
+weight: 10
+---
+
+This section will describe hardware and software prerequisites,
+installing Confidential Containers with an operator,
+verifying the installation,
+and running a pod with Confidential Containers.

content/en/docs/getting-started/prerequisites/hardware/]

@@ -0,0 +1,17 @@
+---
+title: Cloud Hardware 
+description: Confidential Containers on the Cloud 
+weight: 10
+categories:
+- prerequisites
+tags:
+- peer pods
+- cloud api adaptor
+---
+
+Confidential Containers can be deployed via confidential computing cloud offerings.
+The main method of doing this is to use the [cloud-api-adaptor](https://github.com/confidential-containers/cloud-api-adaptor)
+also known as "peer pods."
+
+Some clouds also support starting confidential VMs inside of non-confidential VMs.
+With Confidential Containers these offerings can be used as if they were bare-metal.

content/en/docs/getting-started/prerequisites/hardware/_index.md

@@ -0,0 +1,21 @@
+---
+title: Hardware Requirements 
+description: Hardware requirements for deploying Confidential Containers 
+weight: 10
+---
+
+Confidential Computing is a hardware technology.
+Confidential Containers supports multiple hardware platforms
+and can leverage cloud hardware.
+You can also run Confidential Containers without hardware support
+for testing or development.
+
+The Confidential Containers operator, which is described in the following section,
+does not setup the host kernel, firmware, or system configuration. 
+Before installing Confidential Containers on a bare metal system, 
+make sure that your node can start confidential VMs.
+
+This section will describe the configuration that is required on the host.
+
+Regardless of your platform, it is recommended to have at least 8GB of RAM and 4 cores
+on your worker node.

content/en/docs/getting-started/prerequisites/hardware/cloud.md

@@ -0,0 +1,17 @@
+---
+title: Cloud Hardware 
+description: Confidential Containers on the Cloud 
+weight: 10
+categories:
+- prerequisites
+tags:
+- peer pods
+- cloud api adaptor
+---
+
+Confidential Containers can be deployed via confidential computing cloud offerings.
+The main method of doing this is to use the [cloud-api-adaptor](https://github.com/confidential-containers/cloud-api-adaptor)
+also known as "peer pods."
+
+Some clouds also support starting confidential VMs inside of non-confidential VMs.
+With Confidential Containers these offerings can be used as if they were bare-metal.

content/en/docs/getting-started/prerequisites/hardware/nontee.md

@@ -0,0 +1,19 @@
+---
+title: CoCo without Hardware
+description: Testing and development without hardware 
+weight: 10
+categories:
+- prerequisites
+tags:
+- Non-tee
+---
+
+For testing or development, Confidential Containers can be deployed without
+any hardware support. 
+
+This is referred to as a `coco-dev` or `non-tee`.
+A `coco-dev` deployment functions the same way as Confidential Containers
+with an enclave, but a non-confidential VM is used instead of a confidential VM.
+This does not provide any security guarantees, but it can be used for testing.
+
+No additional host configuration is required as long as the host supports virtualization.

content/en/docs/getting-started/prerequisites/hardware/se.md

@@ -0,0 +1,12 @@
+---
+title: Secure Execution Host Setup 
+description: Host configurations for IBM s390x
+weight: 10
+categories:
+- prerequisites
+tags:
+- SE
+---
+
+TODO
+

content/en/docs/getting-started/prerequisites/hardware/sgx.md

@@ -0,0 +1,12 @@
+---
+title: SGX Host Setup 
+description: Host configurations for Intel SGX machines 
+weight: 10
+categories:
+- prerequisites
+tags:
+- SGX
+---
+
+TODO
+

content/en/docs/getting-started/prerequisites/hardware/snp.md

@@ -0,0 +1,12 @@
+---
+title: SEV-SNP Host Setup 
+description: Host configurations for AMD SEV-SNP machines 
+weight: 10
+categories:
+- prerequisites
+tags:
+- SEV
+---
+
+TODO
+

content/en/docs/getting-started/prerequisites/hardware/tdx.md

@@ -0,0 +1,12 @@
+---
+title: TDX Host Setup 
+description: Host configurations for Intel TDX machines 
+weight: 10
+categories:
+- prerequisites
+tags:
+- TDX
+---
+
+TODO
+

content/en/docs/getting-started/prerequisites/software.md

@@ -0,0 +1,21 @@
+---
+title: Cluster Setup
+description: Cluster prerequisites 
+weight: 20
+categories:
+- prerequisites
+tags:
+- k8s
+---
+
+Confidential Containers requires Kubernetes.
+A cluster must be installed before running the operator.
+Many different clusters can be used but they should meet the following requirements.
+- The minimum Kubernetes version is 1.24
+- Cluster must use `containerd` or `cri-o`.
+- At least one node has the label `node-role.kubernetes.io/worker=`.
+- SELinux is not enabled.
+
+If you use Minikube or Kind to setup your cluster, you will only be able to use
+runtime classes based on Cloud Hypvervisor due to an issue with QEMU.
+

content/en/docs/getting-started/workload.md

@@ -0,0 +1,63 @@
+---
+title: Simple Workload
+description: Running a simple confidential workload 
+weight: 30
+categories:
+- getting-started
+---
+
+## Creating a sample Confidential Containers workload
+
+Once you've used the operator to install Confidential Containers, you can run a pod with CoCo by simply adding a runtime class.
+First, we will use the `kata-qemu-coco-dev` runtime class which uses CoCo without hardware support.
+Initially we will try this with an unencrypted container image.
+
+In this example, we will be using the bitnami/nginx image as described in the following yaml:
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  labels:
+    run: nginx
+  name: nginx
+  annotations:
+    io.containerd.cri.runtime-handler: kata-qemu-coco-dev
+spec:
+  containers:
+  - image: bitnami/nginx:1.22.0
+    name: nginx
+  dnsPolicy: ClusterFirst
+  runtimeClassName: kata-qemu-coco-dev
+```
+
+Setting the `runtimeClassName` is usually the only change needed to the pod yaml, but some platforms
+support additional annotations for configuring the enclave. See the [guides](../guides) for
+more details.
+
+With Confidential Containers, the workload container images are never downloaded on the host.
+For verifying that the container image doesn’t exist on the host, you should log into the k8s node and ensure the following command returns an empty result:
+```
+root@cluster01-master-0:/home/ubuntu# crictl -r unix:///run/containerd/containerd.sock image ls | grep bitnami/nginx
+```
+You will run this command again after the container has started.
+
+Create a pod YAML file as previously described (we named it `nginx.yaml`) .
+
+Create the workload:
+```
+kubectl apply -f nginx.yaml
+```
+Output:
+```
+pod/nginx created
+```
+
+Ensure the pod was created successfully (in running state):
+```
+kubectl get pods
+```
+Output:
+```
+NAME    READY   STATUS    RESTARTS   AGE
+nginx   1/1     Running   0          3m50s
+```

styles/config/vocabularies/coco/accept.txt

@@ -13,17 +13,19 @@ Kubecon
 LLM[s]
 Namespace
 Nginx
+nginx
 OCI
 PCR
 Peerpod
-Qemu
+(?i)qemu
 Rego
 RTMR
 Rivos
 Sched
 SKLearn
 Skopeo
 Unencrypted
+unencrypted
 URI
 VM
 VNet
@@ -55,3 +57,7 @@ transformative
 untrusted
 userland
 virtualized
+(?i)yaml
+[Hh]ypervisor
+Minikube
+SELinux