release notes v0.4.0 initial commit

Signed-off-by: Dan Middleton <dan.middleton@intel.com>

releases/v0.4.0.md

@@ -0,0 +1,67 @@
+# Release Notes for v0.4.0
+Release Date: 2023-03-03 
+
+Please see the [quickstart guide](../quickstart.md) for details on how to try out Confidential Containers
+
+## What's new
+- Skopio and umoci dependencies are removed with our image-rs component fully integrated
+- //add more new stuff here
+
+
+## Hardware Support
+Confidential Containers is tested with attestation on the following platforms:
+- Intel TDX
+- AMD SEV
+
+The following platforms are untested or partially supported:
+- Intel SGX
+- AMD SEV-ES
+- IBM Secure Execution (SE) on IBM zSystems & LinuxONE
+
+The following platforms are in development:
+- AMD SEV-SNP
+
+## Limitations
+
+The following are known limitations of this release:
+
+- Platform support is currently limited, and rapidly changing
+  * AMD SEV-ES is not tested in the CI.
+  * Image signature validation has not been tested with AMD SEV.
+  * s390x does not support cosign signature validation
+- SELinux is not supported on the host and must be set to permissive if in use.
+- Attestation and key brokering support is still under development
+  * The disk-based key broker client (KBC) is used for non-tee testing, but is not suitable for production, except with encrypted VM images.
+  * Currently, there are two KBS that can be used:
+    - simple-kbs:  simple key broker service (KBS) for SEV(-ES).
+    - [Verdictd](https://github.com/inclavare-containers/verdictd): An external project with which Attestation Agent can conduct remote attestation communication and key acquisition via EAA KBC
+  * The full-featured generic KBS and the corresponding KBC are still in the development stage.
+  * For developers, other KBCs can be experimented with.
+  * AMD SEV must use a KBS even for unencrypted images.
+- The format of encrypted container images is still subject to change
+  * The oci-crypt container image format itself may still change
+  * The tools to generate images are not in their final form
+  * The image format itself is subject to change in upcoming releases
+  * Image repository support for encrypted images is unequal
+- CoCo currently requires a custom build of `containerd`
+  * The CoCo operator will deploy the correct version of `containerd` for you
+  * Changes are required to delegate `PullImage` to the agent in the virtual machine
+  * The required changes are not part of the vanilla `containerd`
+  * The final form of the required changes in `containerd` is expected to be different
+  * `crio` is not supported
+- CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
+  * OpenShift is a non-starter at the moment due to its dependency on [CRI-O](https://github.com/cri-o/cri-o)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+  * Container image sharing is not possible in this release
+  * Container images are downloaded by the guest (with encryption), not by the host
+  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/community/issues/66)
+- The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
+  * We track our status with the OpenSSF Best Practices Badge, which increased to 49% at the time of this release.
+  * The main gaps are in test coverage, both general and security tests.
+  * Vulnerability reporting mechanisms also need to be created. Public github issues are still appropriate for this release until private reporting is established.
+
+
+## CVE Fixes
+
+None