github/kata-containers
1
0
Fork 1
mirror of https://github.com/kata-containers/kata-containers.git synced 2025-08-29 04:51:34 +00:00
Code Issues Projects Releases Wiki Activity

doc: Update ccv0 doc and scripts

Browse Source 
- Update the doc and scripts to reflect that skopeo isn't mandatory
for signature verification any longer
- Update the script to default the aa_kbc to offline_fs_kbc

Fixes: #4581
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This commit is contained in:
stevenhorsman 2022-09-07 14:59:55 +01:00 committed by Samuel Ortiz
parent 30460044a5
commit 3aebead189
2 changed files with 33 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/how-to/ccv0.sh
View File

@ -23,6 +23,7 @@ export CRIO=${CRIO:-"no"}
export KATA_HYPERVISOR="${KATA_HYPERVISOR:-qemu}" export KATA_HYPERVISOR="${KATA_HYPERVISOR:-qemu}"
export KUBERNETES=${KUBERNETES:-"no"} export KUBERNETES=${KUBERNETES:-"no"}
export AGENT_INIT="${AGENT_INIT:-${TEST_INITRD:-no}}" export AGENT_INIT="${AGENT_INIT:-${TEST_INITRD:-no}}"
export AA_KBC="${AA_KBC:-offline_fs_kbc}"
# Allow the user to overwrite the default repo and branch names if they want to build from a fork # Allow the user to overwrite the default repo and branch names if they want to build from a fork
export katacontainers_repo="${katacontainers_repo:-github.com/kata-containers/kata-containers}" export katacontainers_repo="${katacontainers_repo:-github.com/kata-containers/kata-containers}"
@ -248,7 +249,7 @@ build_a_custom_kata_agent() {
[ ${ARCH} == "ppc64le" ] && export ARCH=powerpc64le [ ${ARCH} == "ppc64le" ] && export ARCH=powerpc64le
# Run a make install into the rootfs directory in order to create the kata-agent.service file which is required when we add to the rootfs # Run a make install into the rootfs directory in order to create the kata-agent.service file which is required when we add to the rootfs
sudo -E PATH=$PATH make install DESTDIR="${ROOTFS}" sudo -E PATH=$PATH make install DESTDIR="${ROOTFS_DIR}"
popd popd
} }
@ -501,15 +502,23 @@ shim_pull_image() {
} }
call_copy_signature_files_to_guest() { call_copy_signature_files_to_guest() {
# TODO #5173 - remove this once the kernel_params aren't ignored by the agent config
export DEBUG_CONSOLE="true"
if [ "${SKOPEO:-}" = "yes" ]; then
add_kernel_params "agent.container_policy_file=/etc/containers/quay_verification/quay_policy.json" add_kernel_params "agent.container_policy_file=/etc/containers/quay_verification/quay_policy.json"
copy_files_to_guest setup_skopeo_signature_files_in_guest
else
# TODO #4888 - set config to specifically enable signature verification to be on in ImageClient
setup_offline_fs_kbc_signature_files_in_guest
fi
} }
main() { main() {
while getopts "dh" opt; do while getopts "dh" opt; do
case "$opt" in case "$opt" in
d) d)
DEBUG="-d" export DEBUG="-d"
set -x set -x
;; ;;
h) h)

75
docs/how-to/how-to-build-and-test-ccv0.md
View File

@ -37,13 +37,6 @@ $ chmod u+x ccv0.sh
$ export tests_branch=stevenh/add-ccv0-changes-to-build $ export tests_branch=stevenh/add-ccv0-changes-to-build
``` ```
before running the script. before running the script.
- By default `ccv0.sh` enables the agent to use the rust implementation to pull container images on the guest.
If you wish to instead build and include the `skopeo` package for this then run:
```bash
$ export SKOPEO=yes
```
`skopeo` is
required for passing source credentials and verifying container image signatures using the kata agent.
- By default the build and configuration are using `QEMU` as the hypervisor. In order to use `Cloud Hypervisor` instead - By default the build and configuration are using `QEMU` as the hypervisor. In order to use `Cloud Hypervisor` instead
set: set:
``` ```
@ -256,9 +249,6 @@ the `ccv0.sh` script to automatically fill in the variables:
proof of concept to allow more images to be pulled and tested. Once we have support for getting proof of concept to allow more images to be pulled and tested. Once we have support for getting
keys into the Kata guest image using the attestation-agent and/or KBS I'd expect container registry keys into the Kata guest image using the attestation-agent and/or KBS I'd expect container registry
credentials to be looked up using that mechanism. credentials to be looked up using that mechanism.
> **Note**: the native rust implementation doesn't current flow credentials at the moment, so use
the `skopeo` based implementation if they are needed now.
- Run the pull image agent endpoint with - Run the pull image agent endpoint with
```bash ```bash
$ ~/ccv0.sh agent_pull_image $ ~/ccv0.sh agent_pull_image
@ -299,14 +289,13 @@ the `ccv0.sh` script to automatically fill in the variables:
## Verifying signed images ## Verifying signed images
> **Note**: the current proof of concept signature validation code involves hard-coding to protect a specific container For this sample demo, we use local attestation to pass through the required
repository and is only a temporary to demonstrate the function. After the attestation agent is able to pass through configuration to do container image signature verification. Due to this, the ability to verify images is limited
trusted information and the [image management crate](https://github.com/confidential-containers/image-rs) is to a pre-created selection of test images in our test
implemented and integrated this code will be replaced.
For the proof of concept the ability to verify images is limited to a pre-created selection of test images in our test
repository [`quay.io/kata-containers/confidential-containers`](https://quay.io/repository/kata-containers/confidential-containers?tab=tags). repository [`quay.io/kata-containers/confidential-containers`](https://quay.io/repository/kata-containers/confidential-containers?tab=tags).
For pulling images not in this test repository (called an *unprotected* registry below), we can not currently get the GPG keys, or signatures used for signed images, so for compatibility we fall back to the behaviour of not enforcing signatures. For pulling images not in this test repository (called an *unprotected* registry below), we fall back to the behaviour
of not enforcing signatures. More documentation on how to customise this to match your own containers through local,
or remote attestation will be available in future.
In our test repository there are three tagged images: In our test repository there are three tagged images:
@ -319,27 +308,20 @@ In our test repository there are three tagged images:
Using a standard unsigned `busybox` image that can be pulled from another, *unprotected*, `quay.io` repository we can Using a standard unsigned `busybox` image that can be pulled from another, *unprotected*, `quay.io` repository we can
test a few scenarios. test a few scenarios.
In this temporary proof of concept, along with the public GPG key and signature files, a container policy file is In this sample, with local attestation, we pass in the the public GPG key and signature files, and the [`offline_fs_kbc`
created in the rootfs which specifies that any container image from `quay.io/kata-containers` configuration](https://github.com/confidential-containers/attestation-agent/blob/main/src/kbc_modules/offline_fs_kbc/README.md)
must be signed with the embedded GPG key. In order to enable this a new agent configuration parameter called into the guest image which specifies that any container image from `quay.io/kata-containers`
`policy_path` must been provided to the agent which specifies the location of the policy file to use inside the image. must be signed with the embedded GPG key and the agent configuration needs updating to enable this.
The `ccv0.sh` script sets this up automatically by appending With this policy set a few tests of image verification can be done to test different scenarios by attempting
`agent.container_policy_file=/etc/containers/quay_verification/quay_policy.json`
to the `kernel_params` entry in `/etc/kata-containers/configuration.toml`.
With this policy parameter set a few tests of image verification can be done to test different scenarios by attempting
to create containers from these images using `crictl`: to create containers from these images using `crictl`:
> **Note** Until the [issue](https://github.com/kata-containers/kata-containers/issues/3970) to remove `skopeo` from
the guest agent code has been implemented, the Kata confidential-containers build needs to be run with
`export SKOPEO=yes` as documented [above](#basic-script-set-up-and-optional-environment-variables) in order to use the
image signature verification function.
- If you don't already have a Kata sandbox pod created with `crictl`, then follow the - If you don't already have the Kata Containers CC code built and configured for `crictl`, then follow the
[instructions above](#using-crictl-for-end-to-end-provisioning-of-a-kata-confidential-containers-pod-with-an-unencrypted-image) [instructions above](#using-crictl-for-end-to-end-provisioning-of-a-kata-confidential-containers-pod-with-an-unencrypted-image)
up to, and including, the `~/ccv0.sh crictl_create_cc_pod` command. up to the `~/ccv0.sh crictl_create_cc_pod` command.
- In order to enable the guest image, you will need to copy over the policy and signature files needed by running - In order to enable the guest image, you will need to setup the required configuration, policy and signature files
`~/ccv0.sh copy_signature_files_to_guest`and then re-running `~/ccv0.sh crictl_create_cc_pod` which will delete and recreate needed by running
`~/ccv0.sh copy_signature_files_to_guest` and then run `~/ccv0.sh crictl_create_cc_pod` which will delete and recreate
your pod - adding in the new files. your pod - adding in the new files.
- To test the fallback behaviour works using an unsigned image from an *unprotected* registry we can pull the `busybox` - To test the fallback behaviour works using an unsigned image from an *unprotected* registry we can pull the `busybox`
@ -358,16 +340,8 @@ image by running:
$ export CONTAINER_CONFIG_FILE=container-config_unsigned-protected.yaml $ export CONTAINER_CONFIG_FILE=container-config_unsigned-protected.yaml
$ ~/ccv0.sh crictl_create_cc_container $ ~/ccv0.sh crictl_create_cc_container
``` ```
- This results in a - This correctly results in an error message from `crictl`:
`FATA[0001] creating container: rpc error: code = Internal desc = failed to pull image: ExitStatus(unix_wait_status(256))` `PullImage from image service failed" err="rpc error: code = Internal desc = Security validate failed: Validate image failed: The signatures do not satisfied! Reject reason: [Match reference failed.]" image="quay.io/kata-containers/confidential-containers:unsigned"`
message from `crictl` and the Kata log shows that the signature we has was not valid for the unsigned image:
```bash
$ sudo journalctl -xe -t kata --since "1 min ago" | grep "Source image rejected"
```
contains:
```text
Source image rejected: Signature for identity quay.io/kata-containers/confidential-containers:signed is not accepted
```
- To test that the signed image our *protected* test container registry is accepted we can run: - To test that the signed image our *protected* test container registry is accepted we can run:
```bash ```bash
$ export CONTAINER_CONFIG_FILE=container-config.yaml $ export CONTAINER_CONFIG_FILE=container-config.yaml
@ -385,17 +359,8 @@ want to protect with the attestation agent in future) fails we can run:
$ export CONTAINER_CONFIG_FILE=container-config_signed-protected-other.yaml $ export CONTAINER_CONFIG_FILE=container-config_signed-protected-other.yaml
$ ~/ccv0.sh crictl_create_cc_container $ ~/ccv0.sh crictl_create_cc_container
``` ```
- Again this results in a - Again this results in an error message from `crictl`:
`FATA[0001] creating container: rpc error: code = Internal desc = failed to pull image: ExitStatus(unix_wait_status(256))` `"PullImage from image service failed" err="rpc error: code = Internal desc = Security validate failed: Validate image failed: The signatures do not satisfied! Reject reason: [signature verify failed! There is no pubkey can verify the signature!]" image="quay.io/kata-containers/confidential-containers:other_signed"`
message from `crictl` and the Kata log shows a
slightly different error:
```bash
$ sudo journalctl -xe -t kata --since "1 min ago" | grep "Source image rejected"
```
contains:
```text
Source image rejected: Invalid GPG signature
```
### Using Kubernetes to create a Kata confidential containers pod from the encrypted ssh demo sample image ### Using Kubernetes to create a Kata confidential containers pod from the encrypted ssh demo sample image