Add a CI pipeline as close to the Kata Containers one as possible about enclave-cc HOT 15 CLOSED

• provision a server in public cloud
• setup Jenkins
• setup enclave-cc dependencies
• integrate with github actions as runner and prepare basic scripts
• run e2e case
• run operator CI case

from enclave-cc.

operator is one item we definitely should take care of, but we need also let developers have a 'quick' integration path without Kubernets precondition for component test

from enclave-cc.

I'll follow the CI pipeline PR (confidential-containers/operator#133) discussed in the slack channel about monitoring the enclave-cc operator CI state and future extension work.

from enclave-cc.

@stevenhorsman is this issue still relevant or can be closed?
If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?

from enclave-cc.

I believe this is still relevant. It's up to the enclave-cc team as to when they plan to do it, I don't have any input.

from enclave-cc.

I believe this is still relevant. It's up to the enclave-cc team as to when they plan to do it, I don't have any input.

It's relevant and important. I've proposed it to be part of CC-V0.2.0 Drop.

from enclave-cc.

Cool, I've changed the priority to high since you feel it's important :-).

from enclave-cc.

@hairongchen-intel what are the "enclave-cc dependencies"?

from enclave-cc.

@hairongchen-intel what are the "enclave-cc dependencies"?

everything necessary to ensure we can run a component level cases in a host, like the SGX lib, runc/rune, Occlum, containerd/k8s etc.

from enclave-cc.

We should be testing using the operator so the only pre-condition is "kubernetes cluster" and that's not enclave-cc specific

from enclave-cc.

fine but we should not have occlum/rune/sgxsdk pre-installed

from enclave-cc.

For CI pipeline, a simple flowchart is shown below:

build CI payload image -> run CI test cases -> tag release payload image

Some cases are defined for running CI test:

1. [runtime]
   1. Install enclave-cc runtime
   2. Uninstall enclave-cc runtime
2. [feature]
   1. [positive sample] Pull an unencrypted signed image (eaa + verdictd + cosign)
   2. [positive sample] Pull an encrypted unsigned image (eaa + verdictd)
   3. [positive sample] Pull an encrypted signed image (eaa + verdictd + cosign)
   4. [negative sample] Unencrypted signed image with unknown signature is rejected
   5. [negative sample] Encrypted unsigned image with wrong key is rejected
3. [workload]
   1. Deploy a hello-world workload with encrypted signed image
   2. Remove hello-world workload

from enclave-cc.

Some cases are defined for running CI test:

@huliucheng1 thanks, I think this is a good set of cases. do you have any plans where to maintain/publish these test images (e.g., are they being built before the tests or are they something we get to share with Kata-CI)?

from enclave-cc.

making sure using same set of testing images and testing artifacts(policy files, keys, etc..) with kata-cc CI according to https://github.com/kata-containers/tests/tree/CCv0/integration/containerd/confidential/fixtures , Thanks @fidencio for the info

from enclave-cc.

In order to integrate Enclave-CC into the CC operator it needs to build it's own payload image and to demonstrate that Enclave-CC and 'Kata-CC' offer similar levels of functionality the Kata CC tests (or as close as possible) should be run on the Enclave-CC.

Some of the steps have been implemented earlier and after #123 I believe we can meet the original request.

• enclave-cc payloads are published automatically, and tested by operator CI for each PR and in nightly builds. the tests setup a kind cluster and deploys "simulated" enclave-cc on Github runners
• enclave-cc repository builds payloads for both SIM and HW SGX modes, HW mode is tested on an SGX VM w/ eaa_kbc image decryption and cosign based signature verification

from enclave-cc.