CM-830: Integrate trust-manager with cert-manager-operator

[chiragkyal]

Extend cert-manager-operator to deploy and manage trust-manager as an operand, providing a solution for trust bundle distribution on OpenShift.

[openshift-ci-robot]

@chiragkyal: This pull request references CM-830 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Extend cert-manager-operator to deploy and manage trust-manager
as an operand, providing a solution for trust bundle distribution
on OpenShift.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@chiragkyal: This pull request references CM-830 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Extend cert-manager-operator to deploy and manage trust-manager as an operand, providing a solution for trust bundle distribution on OpenShift.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[chiragkyal]

/cc @bharath-b-rh @lunarwhite

[bharath-b-rh]

LGTM mostly. I will need a second read.

[lunarwhite]

It looks fairly good to me 👍. I'm very glad to see that the upstream planned Bundle API changes/deprecations are mentioned in this EP. As we move toward GA (future), we might need to adjust our custom APIs based on the stabilized upstream CRD APIs accordingly.

[mytreya-rh]

• We need to flesh out the defaultca package implementation to avoid/alleviate the cases where the source ConfigMap is not populated in time for the operator to create the operand deployment, and the rollout of operand if the source ConfigMap changes. But this was discussed and we agreed to defer to it during implementation to try out the options.
• w.r.t cluster privileges needed for the operator: We are still waiting on https://redhat-internal.slack.com/archives/C3VS0LV41/p1759755909042599 and thus we will need to take it up later

/lgtm
/hold for @bharath-b-rh and @lunarwhite on design and test aspects
cc: @TrilokGeer

[TrilokGeer]

Is there any specific impact if the trust manager is delivered as default?

[chiragkyal]

Not all the customers would require trust bundle management from day0, hence an explicit opt-in would give them a choice. Customers who need trust-manager can easily enable it by creating a single TrustManager CR. This approach is consistent with how istio-csr is also delivered as an optional day-2 operand in cert-manager-operator.

If we deliver it as default, I think apart from resource overhead challenges for the customers who don't need this operand, there should not be an impact.

[TrilokGeer]

Are there any specific requirements of why these trust bundles need to be in Secrets and not only ConfigMaps?

[chiragkyal]

It depends on how the application wants to use the trust bundle. Some applications might require to read CA bundles exclusively from Secrets. This is an optional feature controlled by secretTargets.policy. By default, trust-manager only writes to ConfigMaps. Administrators explicitly enable Secret targets when their applications require it.

[TrilokGeer]

Is the custom trust namespace an application-specific namespace?

[chiragkyal]

No, the trust namespace is not application-specific. It's a centralized namespace where trust-manager reads source CA certificates from. We are making this option immutable once set.

[TrilokGeer]

Does using CNO directly be better in this case? The user might have better control on the resources that require ca injection.

[chiragkyal]

We will be using CNO to inject default CA certificates into the trust-manager Bundle. Detailed steps are mentioned in the DefaultCAPackage Implementation section.

[bharath-b-rh]

Does using CNO directly be better in this case?

It is specifically for making available the RHCOS bundled CA certificates, user configured certificates for proxy... in case the application need those and is optional. But for distributing CA certificate bundle specifically based on the application need, trust-manager fares better, where instead of distributing all the OpenShift Cluster trusted CA certificates, only required certificates can be made available.

The user might have better control on the resources that require ca injection.

@TrilokGeer Could you please elaborate more this.

[mytreya-rh]

Just to add a bit more to the context:
Whether or not to include the DefaultCA is a parameter (useDefaultCAs) at each bundle level.
Thus, the user has the choice of which bundles will include the DefaultCA, and which will not.

[TrilokGeer]

This might result to a conflict and maybe hard to trace, where an un-intended write will override ca configurations in a namespace.

[chiragkyal]

The targetNamespaces option defines the RBAC for trust-manager. Actual writes are controlled by individual Bundle CRs through namespaceSelector field.

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: my-bundle
spec:
  sources:
    - configMap:
        name: "my-ca"
        key: "ca.crt"
  target:
    configMap:
      key: "ca-bundle.crt"
    # Only writes to namespaces with this label
    namespaceSelector:
      matchLabels:
        trust-bundle-injection: enabled

The actual write behavior is controlled by Bundle CRs, with explicit target naming at the application level.

[bharath-b-rh]

Additionally trust-manager doesn't overwrite the target resource, but instead only appends the configured keys. And yes, if keys with same name exists, that would be a misconfiguration.

[TrilokGeer]

Ideally, this risk must be mitigated by using applicable defaults wherever applicable. Is there any other implementation that cannot be solved by defaults?

[chiragkyal]

The Bundle to ClusterBundle migration will happen in a phased manner in upstream. We can definitely handle Helm value changes and CRD defaults if applicable.
Migration and backward compatibility will be defined by upstream. We'll adapt based on the decision and document any required user actions.

[bharath-b-rh]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bharath-b-rh
Once this PR has been reviewed and has the lgtm label, please ask for approval from mytreya-rh. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• enhancements/cert-manager/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

New changes are detected. LGTM label has been removed.

[openshift-ci]

@chiragkyal: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.