mirror of
https://github.com/confidential-containers/confidential-containers.git
synced 2025-10-21 23:48:29 +00:00
6ef8992bc0
Our link checker is having problems with GH redirects, so let's update these links to point to the right place (even for the old releases). Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
77 lines
4.4 KiB
Markdown
77 lines
4.4 KiB
Markdown
# Release Notes for v0.3.0
|
|
Release Date: January 20th, 2023
|
|
|
|
Code Freeze: January 13th, 2023
|
|
|
|
Please see the [quickstart guide](../quickstart.md) for details on how to try out Confidential Containers
|
|
|
|
## What's new
|
|
- Support for pulling images from authenticated container registries. See [design info](https://github.com/confidential-containers/guest-components/blob/cf1f7f96eb60ec4cc4aaa671c04d574a4ea0e441/docs/image_auth.md).
|
|
- Significantly reduced resource requirements for image pulling
|
|
- Attestation support for AMD SEV-ES
|
|
- `kata-qemu-tdx` supports and has been tested with Verdictd
|
|
- Support for `get_resource` endpoint with SEV(-ES)
|
|
- Enabled cosign signature support in enclave-cc / SGX
|
|
- SEV attestation bug fixes
|
|
- Measured rootfs now works with `kata-clh`, `kata-qemu`, `kata-clh-tdx`, and `kata-qemu-tdx` runtime classes.
|
|
- IBM zSystems / LinuxONE (s390x) enablement and CI verification on non-TEE environments
|
|
- Enhanced docs, config, CI pipeline and test coverage for enclave-cc / SGX
|
|
|
|
## 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/confidential-containers/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/confidential-containers/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
|