[RFC] Helm Chart vs Operator for Trustee Deployment

[zvonkok]

Describe the bug

Background

Trustee can already be installed in Kubernetes via the dedicated trustee-operator CRD.

Yet many users run GitOps pipelines (ArgoCD, Flux, etc.) that treat “a Helm chart in an OCI repo” as the lingua franca for deploying third-party components. For these users, an operator is an extra controller to secure, upgrade and RBAC.

Problem Statement

We need to decide whether the project:

• Officially ships a Helm chart (in-tree or in a sibling repo);
• Continues to recommend only the operator;
• Maintains both, with clear guidance on when to pick which.

Without a clear stance we risk:

• Diverging install paths → fractured bug reports & docs;
• Duplicate effort keeping two deployment artifacts in sync;
• Confusion about versioning (chart vs operator bundle vs Trustee image tag

Helm Chart – Pros / Cons

Aspect	Helm Chart	Operator
Installation UX	1-line helm install, fits GitOps	Requires OLM/OperatorHub or kustomize build && kubectl apply
Lifecycle	Stateless; upgrades are “replace” semantics	Reconciliation & drift-correction built-in
Custom Resources	None (simpler RBAC)	Introduces KbsConfig CRD
Configurability	values.yaml is familiar; can gate features behind --set	CR fields + configmaps; richer validation
Complex orchestrations (micro-services split)	Template logic gets hairy	Operator handles multi-deployment wiring
Security surface	No additional controller to trust	Extra controller, watch permissions

Proposed Next Steps

Gather feedback on questions from maintainers & users.

If consensus emerges to add a chart:

• Draft a minimal POC chart aligning with current operator defaults.
• Automate linting (Chart Testing CI) and OCI artifact publishing.
• Document the new Helm chart flow

[fitzthum]

@lmilleri @bpradipt curious about your views here.

It seems like the Helm chart wouldn't support all of the features that the operator does, but these operator features (like managing resources) don't really fit with Trustee in CoCo. I think it probably would reduce overhead if we had the deployment stuff in the Trustee repo itself.

[Xynnn007]

Some practics from ourselves. We have a downstream fork for trustee and maintain helm-chart inside the repo.

[mythi]

• Maintains both, with clear guidance on when to pick which.

I think we have downstream consumers where the operator based lifecycle management is required. A potential middle ground between the two could be to have a helm chart for the operator.

[gcoon151]

Opinion:
Helm Chart - Desired state as code.
Pros: ... as mentioned this easily fits into gitops because yaml = code.
Cons: No notion of desired state or lifecycle (updates)

Operator

Pros:

• easily picked up via operatorhubs
• lifecycle of trustee which is a pretty critical component built into operators
• In general kube operators implement STRIPS thinking and can work hard to achieve a desired state leveraging kube.

Cons:

• operatorhubs & OLM can have their own issues. I think about in ROKS it's locked down so much who can use operatorhub and that can complicate getting it to use it.

I think the decision of one vs the other decides what target you hope/expect will pick up trustee. I love the simplicity of helm charts but I actually prefer the additional layers that operators handle. It's more than just branches, tags, and releases.

[mythi]

I think the decision of one vs the other decides what target you hope/expect will pick up trustee.

I also think a unified install approach (either Helm or the operator) won't work because "vanilla k8s" users tend to prefer Helm and the operator based flows are commonly used in Openshift environments where the pre-installed OLM nicely integrates with "community operators " from operatorhub.io and Redhat operators.

[lmilleri]

There is also a combined approach in which trustee would have its own helm chart (in same repo or sibling) and an helm-based operator built on top of the chart.

Pros:

• reuse of trustee charts
• OLM operator
• easier to maintain?

Cons:

• limited control flow
• no complex business logic
• less flexibility (the new CR is very similar to the values.yaml in the chart)
• hard to have an abstraction like TrusteeConfig CR

[fitzthum]

What are the key features of the config CR? What would we be missing if we just used a Helm chart vs operator plus Helm chart.

[lmilleri]

This is an example of TrusteeConfig CR:

apiVersion: confidentialcontainers.org/v1alpha1
kind: TrusteeConfig
metadata:
  name: trusteeconfig
  namespace: trustee-operator-system
spec:
  attestationTokenVerificationSpec:
    tlsSecretName: trustee-token-cert
  httpsSpec:
    tlsSecretName: trustee-tls-cert
  kbsServiceType: ClusterIP
  profileType: Restricted

Features:

• abstraction layer: TrusteeConfig CR and HTTPS/token certificates are the only requirements for a secure Trustee deployment. No boiler plate configuration needed. Typically no changes required (from the user pov) when upgrading the trustee release
• simplified deployment: just need to create a simple CR
• TrusteeConfig maps 1:1 with a trustee deployment (1 or more replicas): easy to spawn new trustee instances, possibly enabling other use cases like multi-tenancy, backward compatibility, etc

[fitzthum]

Seems like we could do the same thing with helm, no?

[Xynnn007]

So probably a good direction is to add helm too. No competition here, only implementations tailored to different user scenarios.

[lmilleri]

Adding helm to trustee is definitely a great value added and its integration with the trustee-operator will hopefully happen at some point.

What we'd need is the simplicity of helm charts with its template system and the lifecycle/reconciliation functionality provided by an OLM operator.

These are the options (I found so far):

1. golang-based operator (the current implementation)
2. helm based operator
3. Hybrid Helm Operator (golang + helm)

The 3rd option seems to combine the benefits of option 1 and 3.
For example we can have a 2 tier CR system:

• low level CR that maps directly to the helm values
• high level CR (reconciliated by golang code): this is the user-facing CR with high level parameters (e.g. TrusteeConfig). The golang controller is responsible to translate the high-level CR into the low level CR

[fitzthum]

Btw for reference we have a Helm chart PR now #1150