confidential-containers / trustee-operator

Operator to manage the lifecycle of Trustee (KBS)

Confidential Containers

Welcome to confidential-containers

Confidential Containers is an open source community working to leverage Trusted Execution Environments to protect containers and data and to deliver cloud native confidential computing.

We have a new release every 6 weeks! See Release Notes or Quickstart Guide

Our key considerations are:

• Allow cloud native application owners to enforce application security requirements
• Transparent deployment of unmodified containers
• Support for multiple TEE and hardware platforms
• A trust model which separates Cloud Service Providers (CSPs) from guest applications
• Least privilege principles for the Kubernetes cluster administration capabilities which impact delivering Confidential Computing for guest applications or data inside the TEE

Get started quickly...

• Kubernetes Operator for Confidential Computing : An operator to deploy confidential containers runtime (and required configs) on a Kubernetes cluster

Further Detail

• Project Overview
• Project Architecture
• Our Roadmap
• Alignment with other Projects

Contribute...

• CONTRIBUTING

License

trustee-operator's Issues

Updates to kbsSecretResources is not reflecting

kbsSecretResources is used to make available K8s Secrets to the remote KBS clients. However updating the secrets is not being reflected inside KBS.
This issue is to track the bug.

Add option to provide RVPS measurements via configmap

The following PR confidential-containers/trustee#339 added support to provide reference values via json file.
It'll be good to have this exposed via the operator

kbs deployment doesn't get removed when KbsConfig CRD is deleted

The kbs deployment doesn't get removed when deleting the KbsConfig CRD object (sometimes it gets actually removed though, the issue is not reproducible every time)

Add option to provide TDX specific configuration

For TDX an additional configuration (sgx_default_qcnl.conf) may be required for the AS service.

An example to patch the operator deployment is shown in the following readme

• https://github.com/bpradipt/coco-install/blob/main/misc/kbs-operator-install/tdx.md

This issue is to track the work to integrate this additional configuration on the operator side

cc @fidencio @mythi @lmilleri

Add tests for trustee-operator

At least the following initial tests will be needed

• operator install and uninstall
• Trustee CRD creation, deletion
• secret release
• policy check (deny secret release due to policy deny)
• policy check (allow secret release due to policy allow)
• Update config, secret or policy via modifying the related K8s resources and verifying the update is reflected in the Trustee components
• scaling trustee pods and verifying secret release, policy checks, config updatesetc

Provide quay access to Leonardo to push operator and related images

id: rh_ee_lmilleri

Add option to use External secrets store operator to provide secrets to KBS

External Secrets Operator integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, etc. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.

https://external-secrets.io/latest/

This issue is to track the integration of Trustee operator with external secrets store

Add option to provide resource policy via configmap

Providing a way to override the default KBS policy rego file ( /opa/confidential-containers/kbs/policy.rego ) via configMap will be a good addition for the kbs operator

Q: Does the operator perform state management?

The upstream kbs deployment recipes lack explicit state management and store resources like secrets, policies on a local container instance. There are APIs that allow altering of that pod-local state, which leads to unpredictable results. If the operator would provide facilities and defaults for explicit state (StatefulSet with Volume?) that would be good additional value, and we could point users to the operator as a default means for deploying KBS.

Publish operator in operator hub

Add option to use Secrets Store CSI driver to inject secrets into KBS file store

A secret store CSI driver can be used to inject the secrets into the KBS file store. See the following blog describing how Azure Key Vault Storage is used to inject secrets into the KBS file store - https://confidentialcontainers.org/docs/key-broker-service/kbs-backed-by-akv/
Similar approach can be followed with Hashicorp vault: https://developer.hashicorp.com/vault/docs/platform/k8s/csi

This issue is to track adding support in the operator for the same

Ref: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/usage.html

Enable support for KBS deployment with independent services for RVPS and AS

Currently the KBS deployment is all-in-one. Extend the operator to deploy distributed KBS app as described here - https://github.com/confidential-containers/kbs/blob/main/docker-compose.yml

Rename kbs-operator to trustee-operator in the code