feat: auto-detect TLS security profile from OpenShift cluster

[jcrossley3]

Add support for configuring the trustify server's TLS security profile to align with OpenShift's centralized TLS Security Profiles (Old, Intermediate, Modern, Custom). This works with the new HTTP_SERVER_TLS_SECURITY_PROFILE env var added in trustify TC-3426.

The TLS security profile is resolved with three-tier precedence:

1. User-specified: set tls.securityProfile in the CR spec (as a simple string like "intermediate" or as an object with custom cipher config)
2. Auto-detected: on OpenShift, the operator reads the APIServer CR (config.openshift.io/v1, named "cluster") using Helm's lookup function and extracts spec.tlsSecurityProfile
3. Compiled default: if neither is available (vanilla Kubernetes, or helm template dry-run where lookup returns empty), no env var is set and the trustify server uses its compiled default (modern/TLS 1.3)

For custom profiles, the operator also sets HTTP_SERVER_TLS_MIN_VERSION, HTTP_SERVER_TLS_CIPHERS, and HTTP_SERVER_TLS_CIPHERSUITES. OpenShift's VersionTLS* names (e.g. VersionTLS12) are mapped to trustify's format (e.g. 1.2), and cipher lists are colon-joined.

Changes:

• New _tls_profile.tpl helper with profile resolution and version mapping
• _http.tpl calls the new helper for all HTTP server deployments
• values.schema.yaml adds tls.securityProfile (string or object with type, minTLSVersion, ciphers, ciphersuites)
• RBAC ClusterRole gains get/list on config.openshift.io/apiservers

Implements TC-3426

Summary by Sourcery

Add support for configuring the TLS security profile for HTTP servers, including auto-detection from OpenShift APIServer configuration, while preserving existing defaults.

New Features:

• Introduce a tls.securityProfile Helm value allowing explicit selection or customisation of the TLS security profile, including min TLS version and cipher configuration.
• Add a Helm helper that configures HTTP server TLS-related environment variables based on user settings or OpenShift APIServer TLS security profile.

Enhancements:

• Wire the new TLS security profile helper into existing HTTP server templates so all HTTP deployments respect the resolved profile.

Chores:

• Extend operator RBAC to allow reading OpenShift APIServer resources needed for TLS profile auto-detection.

[sourcery-ai]

Reviewer's Guide

Implements automatic and user-configurable TLS security profile handling for the Trustify HTTP server Helm chart, including OpenShift APIServer auto-detection, explicit CR-driven overrides, and required RBAC to read cluster TLS configuration.

File-Level Changes

Change	Details	Files
Add Helm values schema support for configuring TLS security profiles, including custom profile details.	Introduce tls.securityProfile value which can be either a simple string (old, intermediate, modern) or a structured object. Define validation constraints for custom profiles, including minTLSVersion and lists of TLS 1.2 ciphers and TLS 1.3 ciphersuites. Document that the profile may be auto-detected from the OpenShift APIServer CR when not explicitly set.	helm-charts/redhat-trusted-profile-analyzer/values.schema.yaml
Grant the operator RBAC permissions needed to read OpenShift APIServer TLS security profile configuration.	Extend ClusterRole rules to allow get and list on config.openshift.io/apiservers so the operator can read cluster-wide TLS settings.	config/rbac/role.yaml
Introduce a reusable Helm helper to resolve TLS security profile and emit the appropriate HTTP server environment variables.	Create trustification.tls.securityProfile.envVars helper that determines the effective TLS profile via precedence: user-specified .Values.tls.securityProfile, then OpenShift APIServer CR lookup, otherwise no override. Handle string and map forms of user-specified profiles, including emitting HTTP_SERVER_TLS_SECURITY_PROFILE, and for custom profiles HTTP_SERVER_TLS_MIN_VERSION, HTTP_SERVER_TLS_CIPHERS, and HTTP_SERVER_TLS_CIPHERSUITES with colon-joined cipher lists. When auto-detecting, use Helm lookup on config.openshift.io/v1 APIServer/cluster and translate spec.tlsSecurityProfile into HTTP_SERVER_TLS_SECURITY_PROFILE and related env vars, including mapping OpenShift VersionTLS* to numeric versions via a helper. Add trustification.tls.securityProfile.mapVersion helper to map VersionTLS10/11/12/13 to 1.0/1.1/1.2/1.3, defaulting to the original value if unmapped.	helm-charts/redhat-trusted-profile-analyzer/templates/helpers/_tls_profile.tpl
Wire TLS security profile env var helper into HTTP server deployments.	Invoke trustification.tls.securityProfile.envVars in the HTTP helper so all HTTP server pods get the resolved TLS profile-related environment variables when applicable.	helm-charts/redhat-trusted-profile-analyzer/templates/helpers/_http.tpl

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The trustification.tls.securityProfile.envVars helper expects a root key but _http.tpl calls it with . directly; this will make .root nil in the helper, so either change the helper to use . directly or call it with {{ include "trustification.tls.securityProfile.envVars" (dict "root" .) }}.
• The dig call for the APIServer TLS profile appears mis-ordered: {{- $tlsProfile := dig "spec" "tlsSecurityProfile" dict $apiserver -}} treats "spec" as the default and dict as a key; it should follow the dig DEFAULT KEY1 KEY2 ... COLLECTION contract (e.g. dig dict "spec" "tlsSecurityProfile" $apiserver).
• For auto-detected custom TLS profiles from the OpenShift APIServer, you only propagate minTLSVersion and ciphers but not ciphersuites, which is inconsistent with the user-specified custom profile handling and the PR description that mentions setting HTTP_SERVER_TLS_CIPHERSUITES for custom profiles.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `trustification.tls.securityProfile.envVars` helper expects a `root` key but `_http.tpl` calls it with `.` directly; this will make `.root` nil in the helper, so either change the helper to use `.` directly or call it with `{{ include "trustification.tls.securityProfile.envVars" (dict "root" .) }}`.
- The `dig` call for the APIServer TLS profile appears mis-ordered: `{{- $tlsProfile := dig "spec" "tlsSecurityProfile" dict $apiserver -}}` treats "spec" as the default and `dict` as a key; it should follow the `dig DEFAULT KEY1 KEY2 ... COLLECTION` contract (e.g. `dig dict "spec" "tlsSecurityProfile" $apiserver`).
- For auto-detected custom TLS profiles from the OpenShift APIServer, you only propagate `minTLSVersion` and `ciphers` but not `ciphersuites`, which is inconsistent with the user-specified custom profile handling and the PR description that mentions setting `HTTP_SERVER_TLS_CIPHERSUITES` for custom profiles.

## Individual Comments

### Comment 1
<location path="helm-charts/redhat-trusted-profile-analyzer/templates/helpers/_tls_profile.tpl" line_range="42-43" />
<code_context>
+
+{{- else if eq (include "trustification.openshift.detect" .root) "true" -}}
+  {{/* Auto-detect from OpenShift APIServer CR */}}
+  {{- $apiserver := (lookup "config.openshift.io/v1" "APIServer" "" "cluster") -}}
+  {{- $tlsProfile := dig "spec" "tlsSecurityProfile" dict $apiserver -}}
+  {{- with $tlsProfile -}}
+    {{- $type := .type | lower }}
</code_context>
<issue_to_address>
**issue (bug_risk):** Using `dict` as the default for `dig` may cause `with $tlsProfile` to execute on an empty map and then fail when accessing `.type`.

Because `dig` defaults to `dict`, `$tlsProfile` becomes an empty map when the APIServer resource or its `tlsSecurityProfile` field is missing. Empty maps are truthy in Go templates, so the `with` block still runs and `.type | lower` is evaluated on a value without `type`, likely causing a render error. To avoid this, default to `nil` (or omit the default and handle `nil`) so the `with` block is skipped when the profile is absent:

```tpl
{{- $tlsProfile := dig "spec" "tlsSecurityProfile" nil $apiserver -}}
{{- with $tlsProfile -}}
  {{- $type := .type | lower }}
  ...
{{- end }}
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Using dict as the default for dig may cause with $tlsProfile to execute on an empty map and then fail when accessing .type.

Because dig defaults to dict, $tlsProfile becomes an empty map when the APIServer resource or its tlsSecurityProfile field is missing. Empty maps are truthy in Go templates, so the with block still runs and .type | lower is evaluated on a value without type, likely causing a render error. To avoid this, default to nil (or omit the default and handle nil) so the with block is skipped when the profile is absent:

{{- $tlsProfile := dig "spec" "tlsSecurityProfile" nil $apiserver -}}
{{- with $tlsProfile -}}
  {{- $type := .type | lower }}
  ...
{{- end }}