LOG-8972: Enhance cluster-logging-operator to react to cluster TLS Profile updates by jcantrill · Pull Request #3228 · openshift/cluster-logging-operator

jcantrill · 2026-03-19T17:30:29Z

Summary

This PR enhances the cluster-logging-operator to react to cluster TLS Profile updates, ensuring both the operator itself and deployed collectors use the cluster's TLS security configuration.

Fixes LOG-8972
Blocked by #3238

Changes

Operator's Own TLS Configuration

TLS Conversion Helpers: Added functions to convert OpenShift TLSProfileSpec to Go crypto/tls.Config
Metrics Server: Operator's metrics endpoint now uses cluster TLS profile (cipher suites and min TLS version)
TLS Profile Watcher: New controller that watches for APIServer TLS profile changes and gracefully restarts the operator pod to apply new configuration

Implementation Details

Part A: Operator TLS Configuration

Added internal/tls/tls.go conversion functions:
- CipherSuiteStringToID: Convert cipher suite names to crypto/tls IDs
- TLSVersionToConstant: Convert TLS version strings to crypto/tls constants
- TLSConfigFromProfile: Create crypto/tls.Config from TLSProfileSpec
- GetTLSConfigOptions: Get TLS options for controller-runtime manager
Created internal/controller/tlsprofile/ watcher controller:
- Monitors APIServer resource for TLS profile changes
- Compares current profile to initial startup profile
- Gracefully exits operator pod when changes detected
- Kubernetes automatically restarts pod with new configuration
Updated cmd/main.go:
- Fetch cluster TLS profile at startup
- Configure metrics server with cluster TLS profile
- Register TLS profile watcher controller

Behavior

When Cluster TLS Profile Changes

Operator:

TLS profile watcher detects the change
Operator pod exits gracefully (exit code 0)
Kubernetes restarts the pod (~10 seconds downtime)
New pod applies updated TLS configuration to metrics server

TLS Profile Precedence

Output-specific profile (highest priority)
Cluster TLS profile (default when output doesn't specify)

Testing

Unit Tests

✅ TLS conversion functions: 12/12 tests passing
✅ TLS profile watcher controller: 5/5 tests passing

Verification

✅ make build - Success
✅ make lint - 0 issues
✅ All new unit tests passing

Manual Testing Recommendations

Deploy operator in a test cluster
Verify metrics endpoint uses cluster TLS profile
Change cluster TLS profile: oc patch apiserver cluster --type=merge -p '{"spec":{"tlsSecurityProfile":{"type":"Modern"}}}'
Verify operator pod restarts
Create CLF without output-specific TLS profile
Verify collector uses cluster TLS profile
Change cluster TLS profile again
Verify collector pods are rolled out

RBAC

No changes needed - existing ClusterRole already has permissions to read APIServer resources.

Notes

Why restart the operator? The controller-runtime manager's TLS configuration is set at creation time and cannot be dynamically updated. Restarting is the cleanest way to apply new TLS settings.
Impact on running collectors: The operator restart does not affect running collectors. They continue operating normally during the brief restart period.
TLS Curves: OpenShift's TLSProfileSpec doesn't have a separate field for EC curves. Curves are implicitly controlled by cipher suites (e.g., ECDHE cipher suites use EC curves).
Graceful degradation: If APIServer cannot be fetched, operator logs a warning and uses default TLS configuration (TLS 1.2).

Commits

feat(tls): Add TLS profile conversion helpers for crypto/tls config
feat(controller): Add TLS profile watcher to restart operator on changes
feat(operator): Apply cluster TLS profile to metrics endpoint

Documentation

Follow-up PR needed to update docs/features/tls_security_profile.adoc with:

Operator metrics endpoint uses cluster TLS profile
Automatic reaction to cluster TLS profile changes
Operator restart behavior
Minimal disruption during updates

🤖 Generated with Claude Code via /jira:solve [LOG-8972](https://redhat.atlassian.net/browse/LOG-8972)

openshift-ci-robot · 2026-03-19T17:30:35Z

@jcantrill: This pull request references LOG-8972 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 task to target the "4.8.0" version, but no target version was set.

Details

In response to this:

Summary

This PR enhances the cluster-logging-operator to react to cluster TLS Profile updates, ensuring both the operator itself and deployed collectors use the cluster's TLS security configuration.

Fixes LOG-8972

Changes

Operator's Own TLS Configuration

TLS Conversion Helpers: Added functions to convert OpenShift TLSProfileSpec to Go crypto/tls.Config

Metrics Server: Operator's metrics endpoint now uses cluster TLS profile (cipher suites and min TLS version)

TLS Profile Watcher: New controller that watches for APIServer TLS profile changes and gracefully restarts the operator pod to apply new configuration

Collector TLS Configuration

APIServer Watch: ClusterLogForwarder controller now watches APIServer for TLS profile changes

Automatic Reconciliation: All ClusterLogForwarders are reconciled when cluster TLS profile changes

Collector Rollout: Collector configs are regenerated and pods are rolled out with updated TLS configuration

Implementation Details

Part A: Operator TLS Configuration

Added internal/tls/tls.go conversion functions:

CipherSuiteStringToID: Convert cipher suite names to crypto/tls IDs

TLSVersionToConstant: Convert TLS version strings to crypto/tls constants

TLSConfigFromProfile: Create crypto/tls.Config from TLSProfileSpec

GetTLSConfigOptions: Get TLS options for controller-runtime manager

Created internal/controller/tlsprofile/ watcher controller:

Monitors APIServer resource for TLS profile changes

Compares current profile to initial startup profile

Gracefully exits operator pod when changes detected

Kubernetes automatically restarts pod with new configuration

Updated cmd/main.go:

Fetch cluster TLS profile at startup

Configure metrics server with cluster TLS profile

Register TLS profile watcher controller

Part B: Collector TLS Configuration

Updated internal/controller/observability/clusterlogforwarder_controller.go:

Added watch on config.openshift.io/v1/APIServer

Implemented event handler to enqueue all CLFs on TLS profile changes

Added predicate to filter only TLS profile change events

Behavior

When Cluster TLS Profile Changes

Operator:

TLS profile watcher detects the change

Operator pod exits gracefully (exit code 0)

Kubernetes restarts the pod (~10 seconds downtime)

New pod applies updated TLS configuration to metrics server

Collectors:

All ClusterLogForwarders are enqueued for reconciliation

Each CLF regenerates collector config with new TLS profile

Collector pods are rolled out using Kubernetes rolling update

No log loss (gradual rollout ensures availability)

TLS Profile Precedence

Output-specific profile (highest priority)

Cluster TLS profile (default when output doesn't specify)

Testing

Unit Tests

✅ TLS conversion functions: 12/12 tests passing

✅ TLS profile watcher controller: 5/5 tests passing

Verification

✅ make build - Success

✅ make lint - 0 issues

✅ All new unit tests passing

Manual Testing Recommendations

Deploy operator in a test cluster

Verify metrics endpoint uses cluster TLS profile

Change cluster TLS profile: oc patch apiserver cluster --type=merge -p '{"spec":{"tlsSecurityProfile":{"type":"Modern"}}}'

Verify operator pod restarts

Create CLF without output-specific TLS profile

Verify collector uses cluster TLS profile

Change cluster TLS profile again

Verify collector pods are rolled out

RBAC

No changes needed - existing ClusterRole already has permissions to read APIServer resources.

Notes

Why restart the operator? The controller-runtime manager's TLS configuration is set at creation time and cannot be dynamically updated. Restarting is the cleanest way to apply new TLS settings.

Impact on running collectors: The operator restart does not affect running collectors. They continue operating normally during the brief restart period.

TLS Curves: OpenShift's TLSProfileSpec doesn't have a separate field for EC curves. Curves are implicitly controlled by cipher suites (e.g., ECDHE cipher suites use EC curves).

Graceful degradation: If APIServer cannot be fetched, operator logs a warning and uses default TLS configuration (TLS 1.2).

Commits

feat(tls): Add TLS profile conversion helpers for crypto/tls config

feat(controller): Add TLS profile watcher to restart operator on changes

feat(operator): Apply cluster TLS profile to metrics endpoint

feat(controller): Watch APIServer TLS profile for collector updates

Documentation

Follow-up PR needed to update docs/features/tls_security_profile.adoc with:

Operator metrics endpoint uses cluster TLS profile

Automatic reaction to cluster TLS profile changes

Operator restart behavior

Minimal disruption during updates

🤖 Generated with Claude Code via /jira:solve [LOG-8972](https://redhat.atlassian.net/browse/LOG-8972)

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 · 2026-03-19T17:30:52Z

@jcantrill: This pull request references LOG-8972 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 task to target the "4.8.0" version, but no target version was set.

Details

In response to this:

Summary

This PR enhances the cluster-logging-operator to react to cluster TLS Profile updates, ensuring both the operator itself and deployed collectors use the cluster's TLS security configuration.

Fixes LOG-8972

Changes

Operator's Own TLS Configuration

TLS Conversion Helpers: Added functions to convert OpenShift TLSProfileSpec to Go crypto/tls.Config

Metrics Server: Operator's metrics endpoint now uses cluster TLS profile (cipher suites and min TLS version)

TLS Profile Watcher: New controller that watches for APIServer TLS profile changes and gracefully restarts the operator pod to apply new configuration

Collector TLS Configuration

APIServer Watch: ClusterLogForwarder controller now watches APIServer for TLS profile changes

Automatic Reconciliation: All ClusterLogForwarders are reconciled when cluster TLS profile changes

Collector Rollout: Collector configs are regenerated and pods are rolled out with updated TLS configuration

Implementation Details

Part A: Operator TLS Configuration

Added internal/tls/tls.go conversion functions:

CipherSuiteStringToID: Convert cipher suite names to crypto/tls IDs

TLSVersionToConstant: Convert TLS version strings to crypto/tls constants

TLSConfigFromProfile: Create crypto/tls.Config from TLSProfileSpec

GetTLSConfigOptions: Get TLS options for controller-runtime manager

Created internal/controller/tlsprofile/ watcher controller:

Monitors APIServer resource for TLS profile changes

Compares current profile to initial startup profile

Gracefully exits operator pod when changes detected

Kubernetes automatically restarts pod with new configuration

Updated cmd/main.go:

Fetch cluster TLS profile at startup

Configure metrics server with cluster TLS profile

Register TLS profile watcher controller

Part B: Collector TLS Configuration

Updated internal/controller/observability/clusterlogforwarder_controller.go:

Added watch on config.openshift.io/v1/APIServer

Implemented event handler to enqueue all CLFs on TLS profile changes

Added predicate to filter only TLS profile change events

Behavior

When Cluster TLS Profile Changes

Operator:

TLS profile watcher detects the change

Operator pod exits gracefully (exit code 0)

Kubernetes restarts the pod (~10 seconds downtime)

New pod applies updated TLS configuration to metrics server

Collectors:

All ClusterLogForwarders are enqueued for reconciliation

Each CLF regenerates collector config with new TLS profile

Collector pods are rolled out using Kubernetes rolling update

No log loss (gradual rollout ensures availability)

TLS Profile Precedence

Output-specific profile (highest priority)

Cluster TLS profile (default when output doesn't specify)

Testing

Unit Tests

✅ TLS conversion functions: 12/12 tests passing

✅ TLS profile watcher controller: 5/5 tests passing

Verification

✅ make build - Success

✅ make lint - 0 issues

✅ All new unit tests passing

Manual Testing Recommendations

Deploy operator in a test cluster

Verify metrics endpoint uses cluster TLS profile

Change cluster TLS profile: oc patch apiserver cluster --type=merge -p '{"spec":{"tlsSecurityProfile":{"type":"Modern"}}}'

Verify operator pod restarts

Create CLF without output-specific TLS profile

Verify collector uses cluster TLS profile

Change cluster TLS profile again

Verify collector pods are rolled out

RBAC

No changes needed - existing ClusterRole already has permissions to read APIServer resources.

Notes

Why restart the operator? The controller-runtime manager's TLS configuration is set at creation time and cannot be dynamically updated. Restarting is the cleanest way to apply new TLS settings.

Impact on running collectors: The operator restart does not affect running collectors. They continue operating normally during the brief restart period.

TLS Curves: OpenShift's TLSProfileSpec doesn't have a separate field for EC curves. Curves are implicitly controlled by cipher suites (e.g., ECDHE cipher suites use EC curves).

Graceful degradation: If APIServer cannot be fetched, operator logs a warning and uses default TLS configuration (TLS 1.2).

Commits

feat(tls): Add TLS profile conversion helpers for crypto/tls config

feat(controller): Add TLS profile watcher to restart operator on changes

feat(operator): Apply cluster TLS profile to metrics endpoint

feat(controller): Watch APIServer TLS profile for collector updates

Documentation

Follow-up PR needed to update docs/features/tls_security_profile.adoc with:

Operator metrics endpoint uses cluster TLS profile

Automatic reaction to cluster TLS profile changes

Operator restart behavior

Minimal disruption during updates

🤖 Generated with Claude Code via /jira:solve [LOG-8972](https://redhat.atlassian.net/browse/LOG-8972)

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 · 2026-03-19T17:30:58Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

openshift-ci · 2026-03-19T17:33:30Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jcantrill

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [jcantrill]

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

…s config Add functions to convert OpenShift TLSProfileSpec to Go crypto/tls.Config: - CipherSuiteStringToID: Convert cipher suite names to crypto/tls IDs - TLSVersionToConstant: Convert TLS version strings to crypto/tls constants - TLSConfigFromProfile: Create crypto/tls.Config from TLSProfileSpec - GetTLSConfigOptions: Get TLS config options for controller-runtime manager These helpers enable the operator to apply cluster TLS profiles to its own endpoints (metrics server) by converting OpenShift's TLS configuration format to Go's native crypto/tls types. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

…or on changes Add a new controller that watches the APIServer resource for TLS profile changes and gracefully exits the operator pod when changes are detected. This allows Kubernetes to restart the pod with the new TLS configuration. The controller: - Watches APIServer resource with name "cluster" - Compares current TLS profile to initial startup profile - Exits with code 0 (graceful shutdown) when TLS profile changes - Uses predicates to filter only TLS profile change events This is necessary because the controller-runtime manager's TLS configuration is set at creation time and cannot be changed dynamically. Restarting the pod is the cleanest way to apply new TLS settings to the metrics server. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Configure the operator's metrics server to use the cluster TLS profile: - Fetch cluster TLS profile at operator startup - Apply TLS configuration (cipher suites and min TLS version) to metrics server - Register TLS profile watcher controller to restart on profile changes - Store initial TLS profile for comparison in watcher The metrics server now respects the cluster's TLS security configuration, ensuring the operator adheres to the same security standards as other cluster components. When the cluster TLS profile changes, the operator pod will gracefully restart to apply the new configuration. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

… updates Add APIServer watch to ClusterLogForwarder controller to trigger reconciliation when the cluster TLS profile changes: - Watch APIServer resource for TLS profile changes - Enqueue all ClusterLogForwarders when cluster TLS profile changes - Use predicate to filter only TLS profile change events - Regenerate collector configs with new TLS profile - Roll out collector pods with updated configuration This ensures collectors use the cluster TLS profile for output connections when the ClusterLogForwarder does not specify an output-specific profile. Output-level TLS profiles continue to take precedence over cluster profile. The implementation is non-disruptive: collectors are stateless workloads that are safely rolled out with new configuration using Kubernetes' default rolling update strategy. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

…dicates Both tlsprofile and observability controllers had duplicate predicate implementations for filtering APIServer TLS profile changes. This consolidates the logic into a single shared implementation in the tls package. The shared APIServerTLSProfileChangedPredicate function accepts a reconcileOnCreate parameter to handle the different behavior needs: - tlsprofile controller (false): only watches updates, not creation - observability controller (true): watches both creation and updates This reduces code duplication and makes the predicate logic easier to maintain and test. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

jcantrill · 2026-03-19T19:55:16Z

/test all

jcantrill · 2026-03-20T18:20:12Z

/hold

anpingli

LGTM

jcantrill · 2026-04-15T18:19:48Z

/hold cancel

vparfonov · 2026-04-15T19:46:25Z

+	}
+
+	// Fetch and apply cluster TLS profile
+	tlsOpts, err := internaltls.GetTLSConfigOptions(k8sClient)


GetTLSConfigOptions(k8sClient) calls FetchAPIServerTlsProfile internally and we repeat this call again in line 128

I believe this comment is obsolete with the most recent push

jcantrill · 2026-04-15T20:11:26Z

/hold

openshift-ci-robot · 2026-04-16T20:00:26Z

@jcantrill: This pull request references LOG-8972 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 task to target the "4.8.0" version, but no target version was set.

Details

In response to this:

Summary

This PR enhances the cluster-logging-operator to react to cluster TLS Profile updates, ensuring both the operator itself and deployed collectors use the cluster's TLS security configuration.

Fixes LOG-8972
Blocked by #3238

Changes

Operator's Own TLS Configuration

TLS Conversion Helpers: Added functions to convert OpenShift TLSProfileSpec to Go crypto/tls.Config

Metrics Server: Operator's metrics endpoint now uses cluster TLS profile (cipher suites and min TLS version)

TLS Profile Watcher: New controller that watches for APIServer TLS profile changes and gracefully restarts the operator pod to apply new configuration

Implementation Details

Part A: Operator TLS Configuration

Added internal/tls/tls.go conversion functions:

CipherSuiteStringToID: Convert cipher suite names to crypto/tls IDs

TLSVersionToConstant: Convert TLS version strings to crypto/tls constants

TLSConfigFromProfile: Create crypto/tls.Config from TLSProfileSpec

GetTLSConfigOptions: Get TLS options for controller-runtime manager

Created internal/controller/tlsprofile/ watcher controller:

Monitors APIServer resource for TLS profile changes

Compares current profile to initial startup profile

Gracefully exits operator pod when changes detected

Kubernetes automatically restarts pod with new configuration

Updated cmd/main.go:

Fetch cluster TLS profile at startup

Configure metrics server with cluster TLS profile

Register TLS profile watcher controller

Behavior

When Cluster TLS Profile Changes

Operator:

TLS profile watcher detects the change

Operator pod exits gracefully (exit code 0)

Kubernetes restarts the pod (~10 seconds downtime)

New pod applies updated TLS configuration to metrics server

TLS Profile Precedence

Output-specific profile (highest priority)

Cluster TLS profile (default when output doesn't specify)

Testing

Unit Tests

✅ TLS conversion functions: 12/12 tests passing

✅ TLS profile watcher controller: 5/5 tests passing

Verification

✅ make build - Success

✅ make lint - 0 issues

✅ All new unit tests passing

Manual Testing Recommendations

Deploy operator in a test cluster

Verify metrics endpoint uses cluster TLS profile

Change cluster TLS profile: oc patch apiserver cluster --type=merge -p '{"spec":{"tlsSecurityProfile":{"type":"Modern"}}}'

Verify operator pod restarts

Create CLF without output-specific TLS profile

Verify collector uses cluster TLS profile

Change cluster TLS profile again

Verify collector pods are rolled out

RBAC

No changes needed - existing ClusterRole already has permissions to read APIServer resources.

Notes

Why restart the operator? The controller-runtime manager's TLS configuration is set at creation time and cannot be dynamically updated. Restarting is the cleanest way to apply new TLS settings.

Impact on running collectors: The operator restart does not affect running collectors. They continue operating normally during the brief restart period.

TLS Curves: OpenShift's TLSProfileSpec doesn't have a separate field for EC curves. Curves are implicitly controlled by cipher suites (e.g., ECDHE cipher suites use EC curves).

Graceful degradation: If APIServer cannot be fetched, operator logs a warning and uses default TLS configuration (TLS 1.2).

Commits

feat(tls): Add TLS profile conversion helpers for crypto/tls config

feat(controller): Add TLS profile watcher to restart operator on changes

feat(operator): Apply cluster TLS profile to metrics endpoint

Documentation

Follow-up PR needed to update docs/features/tls_security_profile.adoc with:

Operator metrics endpoint uses cluster TLS profile

Automatic reaction to cluster TLS profile changes

Operator restart behavior

Minimal disruption during updates

🤖 Generated with Claude Code via /jira:solve [LOG-8972](https://redhat.atlassian.net/browse/LOG-8972)

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 · 2026-04-16T22:26:15Z

@jcantrill: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-target	`18d5156`	link	true	`/test e2e-target`
ci/prow/lint	`18d5156`	link	true	`/test lint`

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.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 19, 2026

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 19, 2026

jcantrill added the release/6.6 label Mar 19, 2026

openshift-ci bot added the midstream/Dockerfile A Dockerfile.in sync is needed with midstream label Mar 19, 2026

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 19, 2026

jcantrill force-pushed the LOG-8972 branch from aecac21 to 3e8e69a Compare March 19, 2026 17:36

jcantrill and others added 6 commits March 19, 2026 13:36

move test to actually test public function

18d5156

jcantrill force-pushed the LOG-8972 branch from 3e8e69a to 18d5156 Compare March 19, 2026 18:17

jcantrill force-pushed the LOG-8972 branch from 18d5156 to f250d3f Compare March 20, 2026 18:19

jcantrill marked this pull request as ready for review March 20, 2026 18:19

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 20, 2026

openshift-ci bot requested review from alanconway and vparfonov March 20, 2026 18:20

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 20, 2026

jcantrill force-pushed the LOG-8972 branch from f250d3f to 23b14ef Compare March 23, 2026 18:14

anpingli reviewed Mar 26, 2026

View reviewed changes

This was referenced Apr 1, 2026

LOG-8977: Secure the metrics endpoint to restrict scraping to autorized client #3238

Open

LOG-8973: Enhance the log-file-metrics-exporter to be configurable with TLS Profile that includes curves #3239

Open

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 15, 2026

vparfonov reviewed Apr 15, 2026

View reviewed changes

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 15, 2026

jcantrill force-pushed the LOG-8972 branch from 23b14ef to 18d5156 Compare April 16, 2026 20:06

Conversation

jcantrill commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Operator's Own TLS Configuration

Implementation Details

Part A: Operator TLS Configuration

Behavior

When Cluster TLS Profile Changes

TLS Profile Precedence

Testing

Unit Tests

Verification

Manual Testing Recommendations

RBAC

Notes

Commits

Documentation

Uh oh!

openshift-ci-robot commented Mar 19, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Operator's Own TLS Configuration

Collector TLS Configuration

Implementation Details

Part A: Operator TLS Configuration

Part B: Collector TLS Configuration

Behavior

When Cluster TLS Profile Changes

TLS Profile Precedence

Testing

Unit Tests

Verification

Manual Testing Recommendations

RBAC

Notes

Commits

Documentation

Uh oh!

openshift-ci-robot commented Mar 19, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Operator's Own TLS Configuration

Collector TLS Configuration

Implementation Details

Part A: Operator TLS Configuration

Part B: Collector TLS Configuration

Behavior

When Cluster TLS Profile Changes

TLS Profile Precedence

Testing

Unit Tests

Verification

Manual Testing Recommendations

RBAC

Notes

Commits

Documentation

Uh oh!

openshift-ci bot commented Mar 19, 2026

Uh oh!

openshift-ci bot commented Mar 19, 2026

Uh oh!

jcantrill commented Mar 19, 2026

Uh oh!

jcantrill commented Mar 20, 2026

Uh oh!

anpingli left a comment

Choose a reason for hiding this comment

Uh oh!

jcantrill commented Apr 15, 2026

Uh oh!

vparfonov Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

jcantrill Apr 16, 2026

Choose a reason for hiding this comment

jcantrill commented Mar 19, 2026 •

edited

Loading

openshift-ci-robot commented Mar 19, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Mar 19, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Apr 16, 2026 •

edited by openshift-ci bot

Loading