mirror of
https://github.com/confidential-containers/confidential-containers.git
synced 2025-10-22 15:59:03 +00:00
Compare commits
12 Commits
v0.8.0
...
v0.9.0-alp
Author | SHA1 | Date | |
---|---|---|---|
|
8de20e19e0 | ||
|
243224fc4a | ||
|
fe829c58f2 | ||
|
6341e73c27 | ||
|
110f616894 | ||
|
36ef4d0e3d | ||
|
3861810143 | ||
|
e573995129 | ||
|
1f8b197915 | ||
|
28c94a52a5 | ||
|
51915ac2d5 | ||
|
d82359bcb0 |
179
.github/ISSUE_TEMPLATE/release-check-list.md
vendored
179
.github/ISSUE_TEMPLATE/release-check-list.md
vendored
@@ -8,111 +8,108 @@ assignees: ''
|
||||
|
||||
# v<TARGET_RELEASE>
|
||||
|
||||
## Code freeze
|
||||
## Overview
|
||||
|
||||
- [ ] 1. Update Enclave CC to use the latest commit from image-rs
|
||||
The release process mainly follows from this dependency graph.
|
||||
|
||||
* https://github.com/confidential-containers/enclave-cc/blob/main/src/enclave-agent/Cargo.toml
|
||||
* Change the revision
|
||||
* Run `cargo update -p image-rs`
|
||||
Note that you can point to your own fork here, so you don't actually do changes in the other projects
|
||||
before making sure this step works as expected.
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Trustee --> Versions.yaml
|
||||
Guest-Components --> Versions.yaml
|
||||
Kata --> kustomization.yaml
|
||||
Guest-Components .-> Client-tool
|
||||
Guest-Components --> enclave-agent
|
||||
enclave-cc --> kustomization.yaml
|
||||
Guest-Components --> versions.yaml
|
||||
Trustee --> versions.yaml
|
||||
Kata --> versions.yaml
|
||||
|
||||
- [ ] 2. Update Kata Containers to use the latest commit from image-rs, attestation-agent and td-shim
|
||||
subgraph Kata
|
||||
Versions.yaml
|
||||
end
|
||||
subgraph Guest-Components
|
||||
end
|
||||
subgraph Trustee
|
||||
Client-tool
|
||||
end
|
||||
subgraph enclave-cc
|
||||
enclave-agent
|
||||
end
|
||||
subgraph Operator
|
||||
kustomization.yaml
|
||||
reqs-deploy
|
||||
end
|
||||
subgraph cloud-api-adaptor
|
||||
versions.yaml
|
||||
end
|
||||
```
|
||||
|
||||
* image-rs
|
||||
* https://github.com/kata-containers/kata-containers/blob/CCv0/src/agent/Cargo.toml
|
||||
* Change the revision
|
||||
* Run `cargo update -p image-rs`
|
||||
Note that you can point to your own fork here, so you don't actually do changes in the other projects
|
||||
before making sure this step works as expected.
|
||||
* attestation-agent and td-shim
|
||||
* https://github.com/kata-containers/kata-containers/blob/CCv0/versions.yaml
|
||||
* Change the version
|
||||
Starting with v0.9.0 the release process no longer involves centralized dependency management.
|
||||
In other words, when doing a CoCo release, we don't push the most recent versions of the subprojects
|
||||
into Kata and enclave-cc. Instead, dependencies should be updated during the normal process of development.
|
||||
Releases of most subprojects are now decoupled from releases of the CoCo project.
|
||||
|
||||
- [ ] 3. Wait for kata-runtime-payload-ci to be successfully built
|
||||
* After the previous PR is merged wait for the kata-runtime-payload-ci (https://github.com/kata-containers/kata-containers/actions/workflows/cc-payload-after-push.yaml) has completed, so the latest kata-runtime-payload-ci contains the changes
|
||||
## The Steps
|
||||
|
||||
- [ ] 4. Check if there are new changes in the pre install payload script
|
||||
### Determine release builds
|
||||
|
||||
* https://github.com/confidential-containers/operator/tree/main/install/pre-install-payload
|
||||
* The last commit there must match what's in the following files as preInstall / postUninstall image
|
||||
* Enclave CC: https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml
|
||||
* Kata Containers:
|
||||
Note that for Kata Containers, we're looking for the newTag, below the quay.io/confidential-containers/container-engine-for-cc-payload image
|
||||
* default: https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/default/kustomization.yaml
|
||||
Identify/create the bundles that we will release for Kata and enclave-cc.
|
||||
|
||||
- [ ] 5. Ensure the Operator is using the latest CI builds and that the Operator tests are passsing
|
||||
- [ ] 1. :eyes: **Create enclave-cc release**
|
||||
|
||||
Enclave-cc does not have regular releases apart from CoCo, so we need to make one.
|
||||
Make sure that the CI [is green](https://github.com/confidential-containers/operator/actions/workflows/enclave-cc-cicd.yaml) and then use the Github release tool to create a tag and release.
|
||||
This should create a bundle [here](https://quay.io/repository/confidential-containers/runtime-payload?tab=tags).
|
||||
|
||||
- [ ] 2. :eyes: **Find Kata release version**
|
||||
|
||||
The release will be based on an existing Kata containers bundle.
|
||||
You should use a release of Kata containers.
|
||||
Release bundles can be found [here](https://quay.io/repository/kata-containers/kata-deploy?tab=tags).
|
||||
There is also a bundle built for [each commit](https://quay.io/repository/kata-containers/kata-deploy-ci?tab=tags).
|
||||
If you absolutely cannot use a Kata release,
|
||||
you can consider releasing one of these bundles.
|
||||
|
||||
|
||||
### Test Release with Operator
|
||||
|
||||
- [ ] 3. :eyes: **Check operator pre-installation**
|
||||
|
||||
The operator uses a pre-install container to setup the node.
|
||||
Check that the container matches the dependencies used in Kata
|
||||
and that the operator pulls the most recent version of the container.
|
||||
|
||||
* Check that the version of the `nydus-snapshotter` used by Kata matches the one used by the operator
|
||||
* Compare `nydus-snapshotter` version in Kata [versions.yaml](https://github.com/kata-containers/kata-containers/blob/main/versions.yaml#L291) with the [Makefile](https://github.com/confidential-containers/operator/blob/main/install/pre-install-payload/Makefile#L4) for the operator pre-intall container.
|
||||
* If they do not match, update the operator. This can be part of the PR described in the next step.
|
||||
|
||||
* Make sure that the operator pulls the most recent version of the pre-install container
|
||||
* Find the last commit in the [pre-install directory](https://github.com/confidential-containers/operator/tree/main/install/pre-install-payload)
|
||||
* Make sure that the commit matches the preInstall / postUninstall image specified for [enclave-cc CRD](https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml) and [Kata CRD](https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/default/kustomization.yaml)
|
||||
* If these do not match (for instance if you changed the snapshotter above), update the operator so that they do match. This can be part of the PR described in the next step.
|
||||
|
||||
|
||||
- [ ] 4. :wrench: **Open a PR to the operator to update the release artifacts**
|
||||
|
||||
Update the operator to use the payloads identified in steps 1 and 2.
|
||||
|
||||
There are a number of places where the payloads are referenced. Make sure to update all of the following to the tag matching the latest commit hash from steps 7 and 8:
|
||||
* Enclave CC:
|
||||
* SIM: https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/sim/kustomization.yaml
|
||||
* HW: https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml
|
||||
* Note that we need the quay.io/confidential-containers/runtime-payload-ci registry and enclave-cc-{SIM,HW}-latest tags
|
||||
* [SIM](https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/sim/kustomization.yaml)
|
||||
* [HW](https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml)
|
||||
* Kata Containers:
|
||||
* default: https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/default/kustomization.yaml
|
||||
* peer-pods: https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/peer-pods/kustomization.yaml
|
||||
* [default](https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/default/kustomization.yaml)
|
||||
* [s390x](https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/s390x/kustomization.yaml)
|
||||
* [peer-pods](https://github.com/confidential-containers/operator/blob/main/config/samples/ccruntime/peer-pods/kustomization.yaml)
|
||||
Note that we need the quay.io/confidential-containers/runtime-payload-ci registry and kata-containers-latest tag
|
||||
|
||||
- [ ] 6. Update peer-pods with latest commits of kata-containers and attestation-agent and test it, following the [release candidate testing process](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md#release-candidate-testing)
|
||||
|
||||
- [ ] 7. Cut an attestation-service v<TARGET_RELEASE> and make images for AS and RVPS, if changes happened in the project.
|
||||
**Also, update the [operator version](https://github.com/confidential-containers/operator/blob/main/config/release/kustomization.yaml#L7)**
|
||||
|
||||
### Final Touches
|
||||
|
||||
* https://github.com/confidential-containers/attestation-service
|
||||
* Cut a release (AS/RVPS images will be automatically built triggered by release)
|
||||
- [ ] 5. :trophy: **Cut an operator release using the GitHub release tool**
|
||||
|
||||
- [ ] 8. Cut a guest-components v<TARGET_RELEASE> release
|
||||
- [ ] 5. :green_book: **Make sure to update the [release notes](https://github.com/confidential-containers/confidential-containers/tree/main/releases) and tag/release the confidential-containers repo using the GitHub release tool.**
|
||||
|
||||
- [ ] 9. Cut a td-shim v<TARGET_RELEASE> release, if changes happened in the project
|
||||
- [ ] 7. :hammer: **Poke Wainer Moschetta (@wainersm) to update the release to the OperatorHub. Find the documented flow [here](https://github.com/confidential-containers/operator/blob/main/docs/OPERATOR_HUB.md).**
|
||||
|
||||
- [ ] 10. Update kbs to use the tagged attestation-service and guest-components, cut a release and make image
|
||||
|
||||
* https://github.com/confidential-containers/kbs/blob/main/src/api/Cargo.toml
|
||||
* Change the revision for the `as-types` and `attestation-service` crates (both use `v<TARGET_RELEASE>`) and update the lock file
|
||||
* https://github.com/confidential-containers/kbs/blob/main/tools/client/Cargo.toml
|
||||
* Change the revision for the `as-types` and `kbs_protocol` crates (both use `v<TARGET_RELEASE>`)
|
||||
* Cut a release
|
||||
* kbs image will be automatically built triggered by release, so ensure that the [release workflow](https://github.com/confidential-containers/kbs/actions/workflows/release.yaml) ran successfully
|
||||
|
||||
- [ ] 11. Update Enclave CC to use the released version of image-rs
|
||||
|
||||
* redo step 3, but now using v<TARGET_RELEASE>
|
||||
|
||||
- [ ] 12. Update Kata Containers to the latest released version of:
|
||||
|
||||
* image-rs (redo step 4, but now using the v<TARGET_RELEASE>)
|
||||
* attestation-agent (redo step 5, but now using the v<TARGET_RELEASE>)
|
||||
* td-shim (redo step 6, but now using the v<TARGET_RELEASE>)
|
||||
|
||||
- [ ] 13. Update the operator to use the images generated from the latest commit of both Kata Containers and Enclave CC
|
||||
|
||||
* redo step 8, but now targetting the latest payload image generated for Kata Containers and Enclave CC
|
||||
|
||||
- [ ] 14. Make sure all the operator tests are passing
|
||||
|
||||
- [ ] 15. Cut an Enclave CC release
|
||||
|
||||
- [ ] 16. Add a new Kata Containers tag
|
||||
|
||||
- [ ] 17. Wait for release kata-runtime-payload to be successfully built
|
||||
* After the Kata tag is created wait for (https://github.com/kata-containers/kata-containers/actions/workflows/cc-payload.yaml) to be successfully completed, so the latest commit kata-runtime-payload for the release is created
|
||||
|
||||
- [ ] 18. Update peer pods to use the release versions and then cut a release following the [documented flow](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md#cutting-releases)
|
||||
|
||||
## Release
|
||||
|
||||
|
||||
- [ ] 19. Update the operator to use the release tags coming from Enclave CC and Kata Containers
|
||||
|
||||
* redo step 8, but now targeting the latest release of the payload image generated for Kata Containers eand Enclave CC
|
||||
|
||||
- [ ] 20. Update the Operator version
|
||||
|
||||
* https://github.com/confidential-containers/operator/blob/main/config/release/kustomization.yaml#L7
|
||||
|
||||
- [ ] 21. Cut an operator release
|
||||
|
||||
- [ ] 22. Make sure to update the release notes and tag the confidential-containers repository
|
||||
|
||||
* https://github.com/confidential-containers/documentation/tree/main/releases/v<TARGET_RELEASE>.md
|
||||
|
||||
- [ ] 23. Poke Wainer Moschetta (@wainersm) to update the release to the OperatorHub
|
||||
|
@@ -2,6 +2,8 @@
|
||||
|
||||
# Confidential Containers
|
||||
|
||||
[](https://bestpractices.coreinfrastructure.org/projects/5719)
|
||||
|
||||
## Welcome to confidential-containers
|
||||
|
||||
Confidential Containers is an open source community working to leverage
|
||||
@@ -42,3 +44,4 @@ delivering Confidential Computing for guest applications or data inside the TEE
|
||||
|
||||
## License
|
||||
[](https://app.fossa.com/projects/git%2Bgithub.com%2Fconfidential-containers%2Fcommunity?ref=badge_large)
|
||||
|
||||
|
@@ -75,14 +75,14 @@ Further, as leaders in the community, the SC members will make themselves famili
|
||||
|
||||
The current members of the SC are:
|
||||
|
||||
* Larry Dewey (@larrydewey) - AMD
|
||||
* Larry Dewey (@larrydewey) and Ryan Savino (@ryansavino) - AMD
|
||||
* Jiang Liu (@jiangliu) and Jia Zhang (@jiazhang0) - Alibaba
|
||||
* James Magowan (@magowan) and Tobin Feldman-Fitzthum (@fitzthum) - IBM
|
||||
* Peter Zhu (@peterzcst) and Fabiano Fidêncio (@fidencio) - Intel
|
||||
* Pradipta Banerjee (@bpradipt) and Ariel Adam (@ariel-adam) - Red Hat
|
||||
* Samuel Ortiz (@sameo) - Rivos
|
||||
* Zvonko Kaiser (@zvonkok) - NVIDIA
|
||||
* Vincent Batts (@vbatts) and Ananya Garg (@angarg05) - Microsoft
|
||||
* Vincent Batts (@vbatts) and Dan Mihai (@danmihai1) - Microsoft
|
||||
|
||||
### Emeritus Members
|
||||
|
||||
|
@@ -272,12 +272,12 @@ A tenant-side CoCo Key Broker System cluster includes:
|
||||
- Reference Value Provicer Service (RVPS): Provides reference values for AS.
|
||||
- CoCo Keyprovider: Component to encrypt the images following ocicrypt spec.
|
||||
|
||||
To quick start the KBS cluster, a `docker-compose` yaml is provided to launch.
|
||||
To quick start the KBS cluster, a `docker compose` yaml is provided to launch.
|
||||
|
||||
```shell
|
||||
# Clone KBS git repository
|
||||
git clone https://github.com/confidential-containers/kbs.git
|
||||
cd kbs
|
||||
cd kbs/kbs
|
||||
export KBS_DIR_PATH=$(pwd)
|
||||
|
||||
# Generate a user auth key pair
|
||||
@@ -285,10 +285,10 @@ openssl genpkey -algorithm ed25519 > config/private.key
|
||||
openssl pkey -in config/private.key -pubout -out config/public.pub
|
||||
|
||||
# Start KBS cluster
|
||||
docker-compose up -d
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
If configuration of KBS cluster is required, edit the following config files and restart the KBS cluster with `docker-compose`:
|
||||
If configuration of KBS cluster is required, edit the following config files and restart the KBS cluster with `docker compose`:
|
||||
|
||||
- `$KBS_DIR_PATH/config/kbs-config.json`: configuration for Key Broker Service.
|
||||
- `$KBS_DIR_PATH/config/as-config.json`: configuration for Attestation Service.
|
||||
|
79
releases/v0.9.0-alpha0.md
Normal file
79
releases/v0.9.0-alpha0.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Release Notes for v0.9.0-alpha
|
||||
|
||||
Release Date: May 2nd, 2024
|
||||
|
||||
This is our first release based on Kata Containers main, but it is an alpha release that supports
|
||||
only a subset of features.
|
||||
|
||||
This release is based on [3.4.0](https://github.com/kata-containers/kata-containers/releases/tag/3.4.0) of Kata Containers
|
||||
and [v0.9.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.9.0) of enclave-cc.
|
||||
|
||||
This release supports pulling images inside of the guest with some caveats but it does
|
||||
not support pulling encrypted or signed images inside the guest.
|
||||
This release supports attestation and includes the guest components in the rootfs,
|
||||
but it does not support any TEE platform.
|
||||
Peer pods is also not supported.
|
||||
|
||||
**This release was created mainly for development purposes. For a full feature set,
|
||||
consider returning to v0.8.0 or using the next release.**
|
||||
|
||||
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
|
||||
|
||||
* This release is built from the main branch of Kata Containers.
|
||||
* Non-tee attestation is now based on a sample attester and verifier rather than on `offline_fs_kbc`.
|
||||
* Resources can be dynamically delivered in confidential environments.
|
||||
* Trustee is integrated into the Kata Containers CI.
|
||||
* All platforms now share one confidential rootfs.
|
||||
* All platforms share one confidential guest kernel.
|
||||
* Image request timeout is configurable to facilitate pulling large images.
|
||||
* Attestation Agent now supports generic `configfs-tsm` ABI for collecting evidence.
|
||||
* Enclave-cc moves to unified LibOS bundle for secure rootfs key handling and to the latest Occlum v0.30.1 release that adds SGX EDMM support for dynamically adjusting the enclave size.
|
||||
* Adoption of a project-wide security reporting protocol
|
||||
|
||||
## Hardware Support
|
||||
|
||||
This release does not officially support any hardware platforms.
|
||||
It is mainly intended for testing in non-tee environments.
|
||||
Future releases will return to previous levels of support.
|
||||
|
||||
## 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.
|
||||
* These limitations can apply to the pause image when filesystem passthrough is not enabled.
|
||||
* 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
|
||||
* SELinux is not supported on the host and must be set to permissive if in use.
|
||||
* 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/community/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 75% at the time of this release.
|
||||
* Community has adopted a security reporting protocol, but application and documentation of static and dynamic analysis still needed.
|
||||
* 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
|
||||
|
Reference in New Issue
Block a user