Blog

• Releases
• Release v0.8.0
• Release v0.7.0
• Release v0.6.0
• Release v0.5.0
• Release v0.4.0
• Release v0.3.0
• Release v0.2.0
• Release v0.1.0
• Second blog
• First ever official blog

Releases

Release v0.8.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and 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 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
  • 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

Release v0.7.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and Glossary pages for a definition of the acronyms used in this document.

What’s new

• Flexible instance types/profiles support for peer-pods
• Ability to use CSI Persistent Volume with peer-pods on Azure and IBM Cloud
• EAA-KBC/Verdictd support removed from enclave-cc
• Baremetal SNP without attestation available via operator
• Guest components (attestation-agent, image-rs and ocicrypt-rs) merged into one repository
• Documentation and community repositories merged together

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

The following platforms are in development:

• ARM CCA

Limitations

The following are known limitations of this release:

• 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 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.
• CoCo currently requires a custom build of containerd, which is installed by the operator.
  • Codepath for pulling images will change significantly in future releases.
  • crio is only supported with cloud-api-adaptor.
• 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
  • Some commands accessing confidential data, such as kubectl exec, may either fail to work, or incorrectly expose information to the host
  • Container images must be downloaded separately (inside guest) for each pod. More info
• 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 remained at 64% 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.

CVE Fixes

None

Release v0.6.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and Glossary pages for a definition of the acronyms used in this document.

What’s new

• Support for attesting pod VMs with Azure vTPMs on SEV-SNP
• Support for using Project Amber as an attestation service
• Support for Cosign signature validation with s390x
• Pulling guest images with many layers can no longer cause guest CPU starvation.
• Attestation Service upgraded to avoid several security issues in Go packages.
• CC-KBC & KBS support with SGX attester/verifier for Occlum and CI for enclave-cc

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

The following platforms are in development:

• ARM CCA

Limitations

The following are known limitations of this release:

• 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 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.
• CoCo currently requires a custom build of containerd, which is installed by the operator.
  • Codepath for pulling images will change significantly in future releases.
  • crio is only supported with cloud-api-adaptor.
• 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
  • Some commands accessing confidential data, such as kubectl exec, may either fail to work, or incorrectly expose information to the host
  • Container images must be downloaded separately (inside guest) for each pod. More info
• 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 remained at 64% 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.

CVE Fixes

None

Release v0.5.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and Glossary pages for a definition of the acronyms used in this document.

What’s new

• Process-based isolation is now fully supported with SGX hardware added to enclave-cc CI

• Remote hypervisor support added to the CoCo operator, which helps to enable creating containers as ‘peer pods’, either locally, or on Cloud Service Provider Infrastructure. See README for more information and installation instructions.

• KBS Resource URI Scheme is published to identify all confidential resources.

• Different KBCs now share image encryption format allowing for interchangeable use.

• Generic Key Broker System (KBS) is now supported. This includes the KBS itself, which relies on the Attestation Service (AS) for attestation evidence verification. Reference Values are provided to the AS by the Reference Value Provider Service (RVPS). Currently only TDX and a sample mode are supported with generic KBS. Other platforms are in development.

• SEV configuration can be set with annotations.

• SEV-ES is now tested in the CI.

• Some developmental SEV-SNP components can be manually enabled to test SNP containers without attestation.

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

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
  • Image signature validation with AMD SEV-ES is not covered by CI.
  • 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 varies by platform.
  • The generic KBS is only supported on TDX. Other platforms have different solutions.
• 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 support is not yet complete.
  • Existing APIs do not fully support the CoCo security and threat model. More info
  • 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
• 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 from 49% to 64% at the time of this release.
  • All CoCo repos now have automated tests, including linting, incorporated into CI.
  • Vulnerability reporting mechanisms still need to be created. Public github issues are still appropriate for this release until private reporting is established.

CVE Fixes

None

Release v0.4.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and Glossary pages for a definition of the acronyms used in this document.

What’s new

• This release focused on reducing technical debt. You will not observe as many new features in this release but you will be running on top of more robust code.
• Skopeo and umoci dependencies are removed with our image-rs component fully integrated
• Improved CI for SEV
• Improved container support 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 (s390x) running 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 key broker services (KBS) that can be used:
    • simple-kbs: simple key broker service for SEV(-ES).
    • 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.
• 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
  • Existing APIs do not fully support the CoCo security and threat model. More info
  • 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
• 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

Release v0.3.0

Code Freeze: January 13th, 2023

Please see the quickstart guide for details on how to try out Confidential Containers

What’s new

• Support for pulling images from authenticated container registries. See design info.
• 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: 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
  • Existing APIs do not fully support the CoCo security and threat model. More info
  • 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
• 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

Release v0.2.0

Confidential Containers has adopted a six-week release cadence. This is our first release on this schedule. This release mainly features incremental improvements to our build system and tests as well as minor features, adjustments, and cleanup.

Please see the quickstart guide for details on how to try out Confidential Containers

What’s new

• Kata CI uses existing Kata tooling to build components.
• Kata CI caches build environments for components.
• Pod VM can be launched with measured boot. See more info
• Incremental advances in signature support including verification of cosign-signed images.
• Enclave-cc added to operator, providing initial SGX support.
• KBS no longer required to use unencrypted images with SEV.
• More rigorous versioning of sub-projects

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 Z SE

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
  • s390x is not supported by the CoCo operator
  • AMD SEV-ES has not been tested.
  • AMD SEV does not support container image signature validation.
  • 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: 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
  • Existing APIs do not fully support the CoCo security and threat model. More info
  • 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
• 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 46% 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

Release v0.1.0

This is the first full release of Confidential Containers. The goal of this release is to provide a stable, simple, and well-documented base for the Confidential Containers project. The Confidential Containers operator is the focal point of the release. The operator allows users to install Confidential Containers on an existing Kubernetes cluster. This release also provides core Confidential Containers features, such as being able to run encrypted containers on Intel-TDX and AMD-SEV.

Please see the quickstart guide for details on how to try out Confidential Containers"

Hardware Support

Confidential Containers is tested with attestation on the following platforms:

• Intel TDX
• AMD SEV

The following platforms are untested or partially supported:

• AMD SEV-ES
• IBM Z SE

The following platforms are in development:

• Intel SGX
• AMD SEV-SNP

Limitations

The following are known limitations of this release:

• Platform support is currently limited, and rapidly changing
  • S390x is not supported by the CoCo operator
  • AMD SEV-ES has not been tested.
  • AMD SEV does not support container image signature validation.
• Attestation and key brokering support is still under development
  • The disk-based key broker client (KBC) is used when there is no HW support, 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: 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-started at the moment due to their dependency on CRIO
  • Existing APIs do not fully support the CoCo security and threat model
  • 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.
• 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 was at 43% 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 - This is our first release.

Second blog

Well this is the second blog

First ever official blog

Here is the content of the first blog