mirror of
https://github.com/confidential-containers/confidential-containers.git
synced 2025-05-14 19:09:36 +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>
92 lines
4.9 KiB
Markdown
92 lines
4.9 KiB
Markdown
# Release Notes for v0.8.0
|
|
|
|
Release Date: November 10th, 2023
|
|
|
|
Please see the [quickstart guide](../quickstart.md) for details on how to try out Confidential
|
|
Containers.
|
|
|
|
Please refer to our [Acronyms](https://github.com/confidential-containers/documentation/wiki/Acronyms)
|
|
and [Glossary](https://github.com/confidential-containers/documentation/wiki/Glossary) pages for a
|
|
definition of the acronyms used in this document.
|
|
|
|
## What's new
|
|
|
|
* Upstream containerd supported by all deployment types except enclave-cc.
|
|
* This release includes the Nydus snapshotter (for the first time) to support upstream containerd.
|
|
* In this release images are still pulled inside the guest.
|
|
* **Nydus snapshotter requires the following annotation for each pod `io.containerd.cri.runtime-handler: <runtime-class`.**
|
|
* Support for Nydus snapshotter in peer pods is still experimental. To avoid using it with peer pods do not set above annotation.
|
|
* Nydus snapshotter support in general is still evolving. See limitations section below for details.
|
|
* A new component, the Confidential Data Hub (CDH) is now deployed inside the guest.
|
|
* CDH is an evolution of the Attestation Agent that supports advanced features.
|
|
* CDH supports sealed Kubernetes secrets which are managed by the control plane, but securely unwrapped inside the enclave.
|
|
* CDH supports connections to both KBS and KMS.
|
|
* New architecture of Attestation Agent and CDH allows a client to deploy multiple KBSes.
|
|
* One KBS can be used for validating evidence with the Attestation Service while another can provide resources.
|
|
* Pulling from an authenticated registry now requires `imagePullSecrets`.
|
|
|
|
**Peer Pods**
|
|
* `peerpod-ctl` tool has been expanded.
|
|
* Can check and clean old peerpod objects
|
|
* Adds SSH authentication support to libvirt provider
|
|
* Supports IBM cloud
|
|
* Support for secure key release at runtime and image decryption via remote attestation on AKS
|
|
* Added AMD SEV and IBM s390x support for the Libvirt provider
|
|
* Container registry authentication now bootstrapped from userdata.
|
|
* Enabled public IP usage for pod VM on AWS and PowerVS providers
|
|
* webhook: added IBM ppc64le platform support
|
|
* Support adding custom tags to podvm instances
|
|
* Switched to launching CVM by default on AWS and Azure providers
|
|
* Added rollingUpdate strategy in cloud-api-adaptor daemonset
|
|
* Disabled secureboot by default
|
|
|
|
## Hardware Support
|
|
|
|
Confidential Containers is tested with attestation on the following platforms:
|
|
|
|
* Intel TDX
|
|
* AMD SEV(-ES)
|
|
* Intel SGX
|
|
|
|
The following platforms are untested or partially supported:
|
|
|
|
* IBM Secure Execution (SE) on IBM zSystems (s390x) running LinuxONE
|
|
* AMD SEV-SNP
|
|
* ARM CCA
|
|
|
|
## Limitations
|
|
|
|
The following are known limitations of this release:
|
|
|
|
* Nydus snapshotter support is not mature.
|
|
* Nydus snapshot sometimes conflicts with existing node configuration.
|
|
* You may need to remove existing container images/snapshots before installing Nydus snapshotter.
|
|
* Nydus snapshotter may not support pulling one image with multiple runtime handler annotations even across different pods.
|
|
* Host pulling with Nydus snapshotter is not yet enabled.
|
|
* Nydus snapshotter is not supported with enclave-cc.
|
|
* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
|
|
* `crio` support is still evolving.
|
|
* Platform support is rapidly changing
|
|
* Image signature validation with AMD SEV-ES is not covered by CI.
|
|
* SELinux is not supported on the host and must be set to permissive if in use.
|
|
* The generic KBS does not yet supported all platforms.
|
|
* The format of encrypted container images is still subject to change
|
|
* The [oci-crypt](https://github.com/containers/ocicrypt) 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
|
|
* Not all image repositories support encrypted container images.
|
|
Complete integration with Kubernetes is still in progress.
|
|
* OpenShift support is not yet complete.
|
|
* 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
|
|
* 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 improved to 69% at the time of this release.
|
|
* Vulnerability reporting mechanisms still need to be created. Public github issues are still appropriate for this release until private reporting is established.
|
|
* Container metadata such as environment variables are not measured.
|
|
* Kata Agent does not validate mount requests. A malicious host might be able to mount a shared filesystem into the PodVM.
|
|
|
|
## CVE Fixes
|
|
|
|
None
|
|
|