Skip to content

DPTP-5101: Add E2E test for the TLSAdherence openshift/api field - #31309

Open
richardsonnick wants to merge 1 commit into
openshift:mainfrom
richardsonnick:tls-adherence-e2e
Open

DPTP-5101: Add E2E test for the TLSAdherence openshift/api field#31309
richardsonnick wants to merge 1 commit into
openshift:mainfrom
richardsonnick:tls-adherence-e2e

Conversation

@richardsonnick

@richardsonnickrichardsonnick commented Jun 16, 2026

Copy link
Copy Markdown

Adds E2E tests for the TLSAdherence openshift/api field. This is a requirement for GA.

Summary by CodeRabbit

  • Tests
    • Added new Ginkgo coverage for the TLSAdherence feature gate and API server spec.tlsAdherence behavior.
    • Verifies invalid spec.tlsAdherence values are rejected and valid values (StrictAllComponents, LegacyAdheringComponentsOnly) are accepted.
    • Confirms authorization for viewing and updating API server configuration.
    • Adds wire-level TLS handshake enforcement for non MicroShift/HyperShift clusters based on the configured TLS security profile.
    • TLS-related tests automatically skip when the TLSAdherence gate is disabled.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: automatic mode

@coderabbitai

coderabbitaiBot commented Jun 16, 2026

Copy link
Copy Markdown

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

New extended apiserver tests add TLSAdherence feature-gate gating, validate spec.tlsAdherence dry-run updates, check apiservers/cluster authorization, and assert wire-level TLS handshake behavior for legacy-adhering components.

Changes

TLSAdherence Integration Tests

Layer / File(s)Summary
Feature gate and suite setup
test/extended/apiserver/tls_adherence.go
Adds TLSAdherence gate detection from featuregate/cluster and skips the suite when the gate is disabled.
Spec validation
test/extended/apiserver/tls_adherence.go
Adds dry-run update and patch tests for invalid spec.tlsAdherence values and verifies both supported policy values are accepted.
Access checks
test/extended/apiserver/tls_adherence.go
Adds SubjectAccessReview coverage for update and get on config.openshift.io/v1apiservers/cluster.
Wire-level TLS enforcement
test/extended/apiserver/tls_adherence.go
Adds a TLS connection test that derives expected handshake behavior from TLSSecurityProfile and checks legacy-adhering components against it.

TLS Minimum Versions Context Setup

Layer / File(s)Summary
Local context initialization
test/extended/apiserver/tls.go
TestTLSMinimumVersions initializes a local background context before subsequent API and config requests.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 warning)

Check nameStatusExplanationResolution
Test Structure And Quality⚠️ WarningFAIL: the serial It mutates cluster-scoped apiservers/cluster and its DeferCleanup returns early when TLSAdherence was unset, so the cluster can be left in StrictAllComponents.Always restore a default value in cleanup (e.g. LegacyAdheringComponentsOnly) and split the wire-level checks from the API validation/auth tests.
✅ Passed checks (14 passed)
Check nameStatusExplanation
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage✅ PassedDocstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names✅ PassedAll new Ginkgo Describe/It titles are static string literals; no dynamic IDs, dates, names, or formatted titles were introduced.
Microshift Test Compatibility✅ PassedPASS: each new It has [apigroup:config.openshift.io], and the serial wire-level test also skips MicroShift at runtime.
Single Node Openshift (Sno) Test Compatibility✅ PassedPASS: The new test only uses API/SAR/port-forward checks and skips MicroShift/HyperShift; it never counts or requires multiple nodes or HA topology.
Topology-Aware Scheduling Compatibility✅ PassedE2E tests only; no manifests/controllers or scheduling constraints (nodeSelector, affinity, spread, replica logic) were added.
Ote Binary Stdout Contract✅ PassedNo stdout writes were added in process-level code; the new code only uses test-case logging/printing inside It blocks and helpers.
Ipv6 And Disconnected Network Test Compatibility✅ PassedThe new Ginkgo tests use cluster-internal services and localhost port-forwards only; no IPv4 literals, IPv4-only parsing, or public internet connectivity were added.
No-Weak-Crypto✅ PassedThe patch adds only TLS version checks; no MD5/SHA1/DES/RC4/3DES/Blowfish/ECB, custom crypto, or secret comparisons were introduced.
Container-Privileges✅ PassedChanged files are Go E2E tests only; no privileged/host* fields, SYS_ADMIN, runAsUser:0, or allowPrivilegeEscalation:true were present.
No-Sensitive-Data-In-Logs✅ PassedNo added logging exposes passwords/tokens/PII; new output is limited to test diagnostics like namespaces, TLS modes, and user names.
Title check✅ PassedThe title accurately captures the main change: adding E2E tests for the TLSAdherence field, though the field location is a bit vague.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/extended/apiserver/tls_adherence.go`:
- Around line 120-131: The test assertion in the It block does not account for
the optional spec.tlsAdherence field being unset. Since the field is marked as
optional with omitempty and the test comment acknowledges "when set", the
apiServer.Spec.TLSAdherence value may be nil, causing the BeElementOf assertion
to fail even when the state is valid. Either guard the assertion with a nil
check that conditionally validates only when the field is set, or add the
nil/zero value to the validValues slice so that an unset field is considered a
valid state.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 328d6dfb-fe5e-4dfc-a5f3-811d6c04d0e2

📥 Commits

Reviewing files that changed from the base of the PR and between b3b98a0 and 1f5851c.

📒 Files selected for processing (1)
  • test/extended/apiserver/tls_adherence.go

Comment threadtest/extended/apiserver/tls_adherence.go Outdated
Comment threadtest/extended/apiserver/tls_adherence.go
Comment on lines +63 to +81
g.It("[FeatureGate:TLSAdherence] should have TLSAdherence listed as enabled in featuregate/cluster status [apigroup:config.openshift.io]", func(ctx context.Context) {
fg, err := oc.AdminConfigClient().ConfigV1().FeatureGates().Get(ctx, "cluster", metav1.GetOptions{})
o.Expect(err).NotTo(o.HaveOccurred(), "failed to get featuregate/cluster")

found := false
for _, featureGateValues := range fg.Status.FeatureGates {
for _, enabledGate := range featureGateValues.Enabled {
if enabledGate.Name == tlsAdherenceFeatureGateName {
found = true
break
}
}
if found {
break
}
}
o.Expect(found).To(o.BeTrue(),
"TLSAdherence must appear in featuregate/cluster .status.featureGates[].enabled[].name")
})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't hurt to verify this, but I don't think this should count toward the 5 tests, the intent of which are more functional rather than verifying assumptions.

Comment on lines +134 to +147
// Test 5 – verify that no cluster operator is degraded when the TLSAdherence feature gate is active.
g.It("[FeatureGate:TLSAdherence] should not have any degraded cluster operators [apigroup:config.openshift.io]", func(ctx context.Context) {
coList, err := oc.AdminConfigClient().ConfigV1().ClusterOperators().List(ctx, metav1.ListOptions{})
o.Expect(err).NotTo(o.HaveOccurred(), "failed to list clusteroperators")

for _, co := range coList.Items {
for _, condition := range co.Status.Conditions {
if condition.Type == configv1.OperatorDegraded && condition.Status == configv1.ConditionTrue {
g.Fail(fmt.Sprintf("cluster operator %q is degraded: %s: %s",
co.Name, condition.Reason, condition.Message))
}
}
}
})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is a different kind of test that we can implement that essentially continuously monitors the cluster to verify an invariant is never violated. The way this test is implemented, you'll only get a point in time verification, which would likely result in false negatives.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

Comment threadtest/extended/apiserver/tls_adherence.go Outdated
Comment threadtest/extended/apiserver/tls_adherence.go
@openshift-ciopenshift-ciBot added the ready-for-human-review Indicates a PR has been reviewed by automated tools and is ready for human review label Jun 21, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@richardsonnick

Copy link
Copy Markdown
Author

/test ?

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-aws-ovn-single-node-techpreview

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-gcp-ovn-techpreview

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
test/extended/apiserver/tls_adherence.go (1)

198-210: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Verify Go's short-circuit case evaluation here is intentional and safe.

The case original.Spec.TLSSecurityProfile == nil, original.Spec.TLSSecurityProfile.Type == ...: pattern relies on Go evaluating case expressions left-to-right and stopping at the first match, which prevents a nil dereference when TLSSecurityProfile is nil. This is correct per the Go spec but is a subtle pattern worth a one-line comment for future maintainers, since it's easy to mistakenly "fix" by reordering.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@test/extended/apiserver/tls_adherence.go` around lines 198 - 210, Add a brief
inline comment in the switch over original.Spec.TLSSecurityProfile explaining
that the nil check must come first because Go evaluates case expressions
left-to-right, so the Type access is safe only after the nil case
short-circuits; keep this near the tlsShouldWork/tlsShouldNotWork setup in tls
adherence test logic so future readers do not reorder the cases.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/extended/apiserver/tls_adherence.go`:
- Around line 184-196: The cleanup in the APIServer TLS adherence test does not
actually restore the documented fallback when original.Spec.TLSAdherence was
unset, so the cluster can remain at StrictAllComponents after the test. Update
the DeferCleanup logic in tls_adherence.go to explicitly set the APIServer spec
back to LegacyAdheringComponentsOnly when the original value was empty, and only
skip the update when that fallback is already present; keep the existing restore
path for the APIServer client update using original.Spec.TLSAdherence and the
APIServers().Update flow.
---
Nitpick comments:
In `@test/extended/apiserver/tls_adherence.go`:
- Around line 198-210: Add a brief inline comment in the switch over
original.Spec.TLSSecurityProfile explaining that the nil check must come first
because Go evaluates case expressions left-to-right, so the Type access is safe
only after the nil case short-circuits; keep this near the
tlsShouldWork/tlsShouldNotWork setup in tls adherence test logic so future
readers do not reorder the cases.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 967b6fb4-7f0d-4fb5-a7a4-7f1da3dc89df

📥 Commits

Reviewing files that changed from the base of the PR and between f72bc40 and a910371.

📒 Files selected for processing (2)
  • test/extended/apiserver/tls.go
  • test/extended/apiserver/tls_adherence.go
✅ Files skipped from review due to trivial changes (1)
  • test/extended/apiserver/tls.go

Comment threadtest/extended/apiserver/tls_adherence.go Outdated
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@richardsonnick

Copy link
Copy Markdown
Author

/test ci/prow/e2e-vsphere-ovn

1 similar comment
@richardsonnick

Copy link
Copy Markdown
Author

/test ci/prow/e2e-vsphere-ovn

@richardsonnick

Copy link
Copy Markdown
Author

/test ci/prow/e2e-aws-csi

@richardsonnick

Copy link
Copy Markdown
Author

/test ci/prow/e2e-vsphere-ovn

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@richardsonnick

Copy link
Copy Markdown
Author

/retest-required

@richardsonnick

Copy link
Copy Markdown
Author

/retest-required

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-aws-ovn-microshift

@richardsonnick

Copy link
Copy Markdown
Author

/retest-required

1 similar comment
@richardsonnick

Copy link
Copy Markdown
Author

/retest-required

@openshift-trt

Copy link
Copy Markdown

Risk analysis has seen new tests most likely introduced by this PR.
Please ensure that new tests meet guidelines for naming and stability.

New Test Risks for sha: cee20b8

Job NameNew Test Risk
pull-ci-openshift-origin-main-e2e-gcp-csiHigh - "Find the input image ocp-5.0-upi-installer and tag it into the pipeline"is a new test that was not present in all runs against the current commit.
pull-ci-openshift-origin-main-e2e-gcp-ovnHigh - "Find the input image ocp-5.0-upi-installer and tag it into the pipeline"is a new test that was not present in all runs against the current commit.
pull-ci-openshift-origin-main-e2e-gcp-ovn-upgradeHigh - "Find the input image ocp-5.0-upi-installer and tag it into the pipeline"is a new test that was not present in all runs against the current commit.

New tests seen in this PR at sha: cee20b8

  • "Find the input image ocp-5.0-upi-installer and tag it into the pipeline" [Total: 14, Pass: 14, Fail: 0, Flake: 0]

@richardsonnick

Copy link
Copy Markdown
Author

/retest-required

@richardsonnick

Copy link
Copy Markdown
Author

/assign smg247

@richardsonnick

Copy link
Copy Markdown
Author

@smg247 Hey could you take a look at this PR for us?

@everettraveneverettraven left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handful of comments.

Comment threadtest/extended/apiserver/tls_adherence.go Outdated
Comment on lines +57 to +95
g.It("[FeatureGate:TLSAdherence] should reject an invalid spec.tlsAdherence value on apiservers/cluster [apigroup:config.openshift.io]", func(ctx context.Context) {
current, err := oc.AdminConfigClient().ConfigV1().APIServers().Get(ctx, "cluster", metav1.GetOptions{})
o.Expect(err).NotTo(o.HaveOccurred(), "failed to get apiservers/cluster")

desired := current.DeepCopy()
desired.Spec.TLSAdherence = configv1.TLSAdherencePolicy("InvalidValue")

_, err = oc.AdminConfigClient().ConfigV1().APIServers().Update(ctx, desired, metav1.UpdateOptions{
DryRun: []string{metav1.DryRunAll},
})
o.Expect(err).To(o.HaveOccurred(),
"apiservers/cluster should reject an invalid spec.tlsAdherence value")
o.Expect(k8serrors.IsInvalid(err)).To(o.BeTrue(),
"error should be a 422 Invalid, got: %v", err)
})

g.It("[FeatureGate:TLSAdherence] should accept and reflect all valid spec.tlsAdherence values on apiservers/cluster [apigroup:config.openshift.io]", func(ctx context.Context) {
validValues := []configv1.TLSAdherencePolicy{
configv1.TLSAdherencePolicyStrictAllComponents,
configv1.TLSAdherencePolicyLegacyAdheringComponentsOnly,
}

for _, value := range validValues {
current, err := oc.AdminConfigClient().ConfigV1().APIServers().Get(ctx, "cluster", metav1.GetOptions{})
o.Expect(err).NotTo(o.HaveOccurred(), "failed to get apiservers/cluster")

desired := current.DeepCopy()
desired.Spec.TLSAdherence = value

result, err := oc.AdminConfigClient().ConfigV1().APIServers().Update(ctx, desired, metav1.UpdateOptions{
DryRun: []string{metav1.DryRunAll},
})
o.Expect(err).NotTo(o.HaveOccurred(),
"apiservers/cluster should accept spec.tlsAdherence=%s", value)
o.Expect(result.Spec.TLSAdherence).To(
o.Equal(value),
"apiservers/cluster should reflect spec.tlsAdherence=%s", value)
}
})

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't these already covered by integration tests in the openshift/api repo?

E2E tests are significantly more expensive to run than those, so I would avoid duplicating existing integration tests for an API.

If the integration tests don't exist for the API, let's make sure we add them in openshift/api.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 2 runtime tests that need a live cluster to replace these:

  • Omitted value — confirms components still enforce the profile as LegacyAdheringComponentsOnly when tlsAdherence is unset.
  • Override precedence — confirms IngressController's explicit override wins over the cluster-wide StrictAllComponents profile.

Comment threadtest/extended/apiserver/tls_adherence.go Outdated
Comment on lines +143 to +150
// checkLegacyAdheringComponents verifies that kube-apiserver and the OpenShift
// API servers honour the cluster-wide TLS profile at the wire level.
checkLegacyAdheringComponents := func() {
for _, target := range []struct{ name, namespace, port string }{
{"apiserver", "openshift-kube-apiserver", "443"},
{"api", "openshift-apiserver", "443"},
{"api", "openshift-oauth-apiserver", "443"},
} {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this an exhaustive list of components that must support both modes prior to promotion?

Comment on lines +201 to +214
candidates := []nonLegacyComponent{
{
name: "cluster-control-plane-machine-set-operator",
namespace: "openshift-machine-api",
serviceName: "control-plane-machine-set-operator",
webhookPort: "9443",
},
{
name: "cluster-baremetal-operator",
namespace: "openshift-machine-api",
serviceName: "baremetal-operator-webhook-service",
webhookPort: "9443",
},
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this an exhaustive list of components that must support StrictAllComponents prior to promotion?

@richardsonnickrichardsonnickJul 23, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No there is no defined exhaustive list.
The closest thing that exists is the "Scope and Component Expectations" section, which says all core components honor the cluster-wide profile by default, with exceptions for the Ingress Controller, Kubelet, Routes and Gateway Controller supporting an optional per-component override.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible for us to define this list and ensure they are all meeting the criteria via this testing?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can expand the list of components under test here, but this would require keeping track of the exposed ports of each component, which can become flaky/stale as components change. There's already a periodic-tls13-adherence job (runs every 72h) using openshift/tls-scanner in prow CI that provisions a cluster with tlsAdherence: StrictAllComponents and discovers and scans every open port on every pod in the cluster. This test uniquely verifies the live LegacyAdheringComponentsOnly → StrictAllComponents transition and behavioral change and adding every component here would be a duplicate harder to maintain version of tls-scanner's coverage.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK.

Is there a test name associated with that job that we can track stability of as part of the promotion process?

Would be helpful to have signal into what components are/are not updated yet before we promote the feature gate.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test tracks stability periodically against StrictAllComponents: periodic-ci-openshift-tls-scanner-main-periodic-tls13-adherence. Failures in this test surface which components are not abiding by the tlsAdherence flag properly (there are still a couple of components that are non-compliant). The signal is per-component, so it emits a junit testcase per each pod/port/service.

Here's a list of the current non-compliant components:

  • loki-promtail
  • cluster-baremetal-operator
  • console

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@richardsonnick
richardsonnickforce-pushed the tls-adherence-e2e branch 2 times, most recently from 7bc8efb to 6279f4eCompareJuly 23, 2026 16:36
@smg247

Copy link
Copy Markdown
Member

/approve

@openshift-ci

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joelanford, richardsonnick, smg247

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:

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

@openshift-ciopenshift-ciBot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 23, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-gcp-ovn-upgrade
/test e2e-vsphere-ovn
/test e2e-aws-ovn-serial-2of2

@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-aws-ovn-serial-2of2

1 similar comment
@richardsonnick

Copy link
Copy Markdown
Author

/test e2e-aws-ovn-serial-2of2

@openshift-ci

Copy link
Copy Markdown
Contributor

@richardsonnick: 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.

@richardsonnickrichardsonnick changed the title Add E2E test for the TLSAdherence openshift/api fieldDPTP-5101: Add E2E test for the TLSAdherence openshift/api fieldJul 28, 2026
@openshift-ci-robotopenshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 28, 2026
@openshift-ci-robot

openshift-ci-robot commented Jul 28, 2026

Copy link
Copy Markdown

@richardsonnick: This pull request references DPTP-5101 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 "5.0.0" version, but no target version was set.

Details

In response to this:

Adds E2E tests for the TLSAdherence openshift/api field. This is a requirement for GA.

Summary by CodeRabbit

  • Tests
  • Added new Ginkgo coverage for the TLSAdherence feature gate and API server spec.tlsAdherence behavior.
  • Verifies invalid spec.tlsAdherence values are rejected and valid values (StrictAllComponents, LegacyAdheringComponentsOnly) are accepted.
  • Confirms authorization for viewing and updating API server configuration.
  • Adds wire-level TLS handshake enforcement for non MicroShift/HyperShift clusters based on the configured TLS security profile.
  • TLS-related tests automatically skip when the TLSAdherence gate is disabled.

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.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approvedIndicates a PR has been approved by an approver from all required OWNERS files.jira/valid-referenceIndicates that this PR references a valid Jira ticket of any type.ready-for-human-reviewIndicates a PR has been reviewed by automated tools and is ready for human review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@richardsonnick@joelanford@smg247@openshift-ci-robot@candita@everettraven