feat: Support putting TrustStore information in Secret

[sbernauer]

Description

Small follow-up of #557

This PR allows the Trustore information (such as the ca.crt) to not only be put in a ConfigMap, but also a Secret.
This was requested by a customer, they mentioned it is required by OpenShift routes, but didn't check that.

The first commit is only test refactoring, I'd suggest reviewing it separately.

CRD change

apiVersion: secrets.stackable.tech/v1alpha1
kind: TrustStore
spec:
  secretClassName: tls
  format: tls-pem

  # New field targetKind:
  targetKind: ConfigMap # or Secret, defaults to ConfigMap

Actual schema change

                targetKind:
                  default: ConfigMap
                  description: |-
                    Which Kubernetes resource should be used to output the requested information to.
                    The trust information (such as a `ca.crt`) can be considered public information, so we put it in a `ConfigMap` by default. However, some tools (such as OpenShift routes) require it to be placed in a `Secret`, so we also support that.
                    Can be either `ConfigMap` or `Secret`, defaults to `ConfigMap`.
                  enum:
                    - Secret
                    - ConfigMap
                  type: string

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Helm chart can be installed and deployed operator works
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added
• Roadmap has been updated

[nightkr]

Hm, Route.spec.tls.destinationCACertificate looks like it wants the certificate inline, so I'm not sure how this would help.

I also have a vague memory of that we ran into some issues around OpenShift expecting the certificates to use relative hostnames rather than FQDNs...

[sbernauer]

I had the same observation, but I think I wouldn't focus to much an OpenShift in particular here.
Customer didn't reply yet, but I guess it's not unrealistic that some tools requires it as Secret, so given the easy implementation I personally would just add it. Would really suck for a customer if he can't use TrustStore because an oversight.

[siegfriedweber]

The field outputResource could be named targetResource (similar to targetPort in Services) or targetKind because Secret and ConfigMap are kinds, not resources (which are instances of kinds).

[sbernauer]

I searched a bit and could not find a real world CRD example. But happy if someone else finds one :)
@siegfriedweber I like the idea of targetKind, will update the PR

[sbernauer]

Please vote for this CRD change on this comment

[sbernauer]

Hm, Route.spec.tls.destinationCACertificate looks like it wants the certificate inline, so I'm not sure how this would help.

A customer today asked for this, and mentioned

Could we tell the TrustStore CRD to create a secret instead of a ConfigMap?
The route config on an Ingress only accepts secret references, not ConfigMaps:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/networking/configuring-routes#creating-re-encrypt-route-with-custom-certificate_route-configuration

this should clarify that OpenShift expects it as a Secret

[sbernauer]

Decision approved

[NickLarsenNZ]

LGTM. Do we need doc updates?

[NickLarsenNZ]

I missed the boat on this, but I think Secret should be the default.
I assume ConfigMap was chosen as a default for good reason, so please continue.

[NickLarsenNZ]

Oh I guess because that was the existing behaviour.

[sbernauer]

Correct, existing behavior is a ConfigMap. If we would default to Secret it's breaking ;)
Also I recall someone in a discussion saying that we should try to be transparent that this is not confidential data.

[sbernauer]

Do we need doc updates?

Added to concepts page in 7613599