Description:

This PR adds the ability to configure the cipher suites for the different components in OCP

It also adds remediations / makes them configurable and fixes some minor rendering issues in the texts.

Rationale:

Customers have to comply to different Security Standards
PCI-DSS, CIS, BSI see different Ciphers as secure
There is change in what is considered secure across the time, thus these ciphers might change
Customers will need time to move from one cipher-suite-set to another
Fixes https://issues.redhat.com/browse/RFE-6859

Review Hints:

Some of the fixes need openSSL Notation, while the checks check in IANA notation. This table should help mapping them

IANA	openSSL	OCP Intermediate	Mozilla Intermediate	BSI	APIServer
TLS_AES_128_GCM_SHA256	TLS_AES_128_GCM_SHA256	YES	YES	YES	Default
TLS_AES_256_GCM_SHA384	TLS_AES_256_GCM_SHA384	YES	YES	YES	Default
TLS_CHACHA20_POLY1305_SHA256	TLS_CHACHA20_POLY1305_SHA256	YES	YES	NO	Default
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	ECDHE-ECDSA-AES128-GCM-SHA256	YES	YES	YES	Default
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE-RSA-AES128-GCM-SHA256	YES	YES	YES	Default
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	ECDHE-ECDSA-AES256-GCM-SHA384	YES	YES	YES	Default
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	ECDHE-RSA-AES256-GCM-SHA384	YES	YES	YES	Default
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256	ECDHE-ECDSA-CHACHA20-POLY1305	YES	YES	NO	Default
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256	ECDHE-RSA-CHACHA20-POLY1305	YES	YES	NO	Default
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	DHE-RSA-AES128-GCM-SHA256	YES	YES	YES
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	DHE-RSA-AES256-GCM-SHA384	YES	YES	YES
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256	DHE-RSA-CHACHA20-POLY1305	NO	YES	NO

etcd:

The Regex is kinda complicated but looks for all TLS_ ciphers and matches them. Any TLS_ ciphers not in the list, let the regex fail.
there is no remediation, since etcd uses the ciphers configured in the apiserver. We could make this more obvious in the instructions.

apiserver:

the remediation might not work on HCP clusters.
the remediation will cause a administrative interruption (unavailability of oauth and apiserver for a couple of minutes)
I removed "AES256-GCM-SHA384" and "AES128-GCM-SHA256" as they are considered OLD and not part of intermediate profile (https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29)
oc get apiserver cluster -oyaml does not provide the same output as oc get configmap config -n openshift-kube-apiserver -ojson | jq -r '.data["config.yaml"]' | jq '.servingInfo'. The format is different and also DHE-RSA-AES128-GCM-SHA256 and DHE-RSA-AES256-GCM-SHA384 are rejected
the BSI String does not include the DHE Ciphers, as they are considered insecure from 2029 on, while the Rest is considered secure for 2031+. As they wont be realistically used anyway due to the cipher order, we can leave them out.

ingresscontroller:

the order of the ciphers might not be perfect. I followed the preconfigured order of the old check.
I removed "AES256-GCM-SHA384" and "AES128-GCM-SHA256" as they are considered OLD and not part of intermediate profile (https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29)
the default string in the tls_cipher_suite is identical to the one in the remediation. I would recommend to change this to the mozilla intermediate, as it puts TLS1.3 first. It also has a couple of DH algos (which are considered less secure all in all)

This are the result tables, of my manual tests:

configuration	component	automatic check BSI	automatic check default	Remediation BSI
intermediate (default)	apiserver	fail (expected)	pass	LGTM
intermediate (default)	etcd	fail (expected)	pass	N.A (expected)
intermediate (default)	ingresscontroller	fail (expected)	pass	LGTM
intermediate (default)	kubelet	fail (expected)	pass	LGTM

configuration	component	automatic check BSI	automatic check default	Remediation BSI
after BSI Remediation	apiserver	PASS	PASS	WORKING (service interruption possible for control plane)
after BSI Remediation	etcd	PASS	PASS	N.A (expected)
after BSI Remediation	ingresscontroller	PASS	PASS	WORKING
after BSI Remediation	kubelet	PASS	PASS	WORKING (applied both master & worker at the same time), rerun BSI and default checks

While the changes to the BSI profile could be a separate PR, I think it is easier to use it directly in testing, as the pipeline will get triggered.

Examples of manually configured Tailored Profiles do look like that:

kind: TailoredProfile
apiVersion: compliance.openshift.io/v1alpha1
metadata:
  name: bsi-tr-02102-2-ocp4-node
  namespace: openshift-compliance
spec:
  description: BSI Configuration for profile
  extends: upstream-ocp4-test-node
  setValues:
    - name: upstream-ocp4-var-kubelet-tls-cipher-suites
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: '"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"'
    - name: upstream-ocp4-var-kubelet-tls-cipher-suites-regex
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: ^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384|TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256|TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256|TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384|TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384|TLS_DHE_RSA_WITH_AES_128_GCM_SHA256|TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)$
  title: My little TR-02102-2 node profile

kind: TailoredProfile
apiVersion: compliance.openshift.io/v1alpha1
metadata:
  name: bsi-tr-02102-2-ocp4
  namespace: openshift-compliance
spec:
  description: BSI Configuration for profile
  extends: upstream-ocp4-test
  setValues:
    - name: upstream-ocp4-var-apiserver-tls-cipher-suites
      rationale: APISERVER 2024-01-BSI-TR-02102-2
      value: '"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384","ECDHE-ECDSA-AES128-GCM-SHA256","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384"'
    - name: upstream-ocp4-var-apiserver-tls-cipher-suites-regex
      rationale: APISERVER 2024-01-BSI-TR-02102-2
      value: ^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384|TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256|TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256|TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384|TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)$
    - name: upstream-ocp4-var-etcd-tls-cipher-suites-regex
      rationale: ETCD 2024-01-BSI-TR-02102-2
      value: 'value: \"(?=.*TLS_(?:AES_128_GCM_SHA256|AES_256_GCM_SHA384|ECDHE_ECDSA_WITH_AES_128_GCM_SHA256|ECDHE_RSA_WITH_AES_128_GCM_SHA256|ECDHE_ECDSA_WITH_AES_256_GCM_SHA384|ECDHE_RSA_WITH_AES_256_GCM_SHA384|DHE_RSA_WITH_AES_128_GCM_SHA256|DHE_RSA_WITH_AES_256_GCM_SHA384))(?!.*TLS_(?!AES_128_GCM_SHA256|AES_256_GCM_SHA384|ECDHE_ECDSA_WITH_AES_128_GCM_SHA256|ECDHE_RSA_WITH_AES_128_GCM_SHA256|ECDHE_ECDSA_WITH_AES_256_GCM_SHA384|ECDHE_RSA_WITH_AES_256_GCM_SHA384|DHE_RSA_WITH_AES_128_GCM_SHA256|DHE_RSA_WITH_AES_256_GCM_SHA384)[A-Z0-9_]+).*\"'
    - name: upstream-ocp4-var-ingresscontroller-tls-cipher-suites-regex
      rationale: INGRESSCONTROLLER 2024-01-BSI-TR-02102-2
      value: ^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384|ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-ECDSA-AES256-GCM-SHA384|ECDHE-RSA-AES256-GCM-SHA384|DHE-RSA-AES128-GCM-SHA256|DHE-RSA-AES256-GCM-SHA384)$
    - name: upstream-ocp4-var-ingresscontroller-tls-cipher-suites
      rationale: INGRESSCONTROLLER 2024-01-BSI-TR-02102-2
      value: '"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384","ECDHE-ECDSA-AES128-GCM-SHA256","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384"'  title: My little TR-02102-2 profile
    title: My little TR-02102-2 profile

Sep 05 '25 07:09 sluetze

Hi @sluetze. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

Sep 05 '25 07:09 openshift-ci[bot]

This looks like a sound, reasonable change to make. Only curious if we also want to add a parameter for the minimum TLS version since I think that could be useful for people looking for PQC-safe algorithms.

conclusion

We cannot remove the minTLSVersion option, as it is needed to apply the remediation. If we make it configurable with a variable we have to ensure, that the variable is in sync with the currently existing rules (see table below).

From my understanding the minTLSVersion should not matter for the PQC usecase. If you want to ensure PQC safe ciphers, then just provide them in the Cipher list and no others. You do not need to set minTLSVersion here, as you will not have any TLS1.2 ciphers that you offer.

In my understanding the minTLSVersion is like a "filter" for the cipher list. if there is minTLSVersion: 1.3 the server offers only the configured ciphers from the cipherlist which are available in TLS 1.3.

that being said, I can create variables for the minTLSVersion, but for this I would also:

move tls_version_apiserver to apiserver_tls_min_version add variables for regex and text, and add a remediation
replace tls_version_masters_workers with kubelet_configure_tls_min_version and remove tls_version_masters_workers
move tls_version_check_router to ingress_controller_tls_min_version add variables for regex and text, and add a remediation

rationale: I am not a hundert percent sure with the variable scopes, but iirc they are kind of "group scoped" so I need to move the rules to the same folder anyway. nevertheless it would be quite irritating if we would have a variable in a folder (i.e. networking) which is reused elsewhere (general). The renaming would fit in better with the rest of the rules.

risk: renaming the rules of course might break tailoredprofiles which exclude or include these rules.

long version

Oh no a rabbit-hole :(

There are separate rules for minTLSVersion

Name	Object	variable	Regex	Remediation
kubelet_configure_tls_min_version	kubelet	YES (`var_kubelet_tls_min_version` and `var_kubelet_tls_min_version_regex`	`"^(?!VersionTLS10\|VersionTLS11)"`	YES with kubeletConfig
tls_version_apiserver	/api/v1/namespaces/openshift-apiserver/configmaps/config	NO	`VersionTLS1[2-9]{1}`	NO
tls_version_masters_workers	/etc/kubernetes/kubelet.conf	NO	`VersionTLS1[2-9]{1}`	NO
tls_version_check_router	/apis/apps/v1/namespaces/openshift-ingress/deployments/router-default	NO	`TLSv1.[2-9]{1}`	NO
`api_server_tls_security_profile_custom_min_tls_version`	/apis/config.openshift.io/v1/apiservers/cluster	NO	`"^(?!VersionTLS10\|VersionTLS11)"`	NO

the kubelet_configure_tls_min_version and tls_version_masters_workers check the same configuration but on different ways as far as I understand it. So they are redundant.

I wanted to understand the behavior of remediations which target the same part of the config and how they would interact. So I tested this with kubelet and ingresscontroller.

removing minTLSVersion

this seems to not be a good option.

security profile has invalid minimum security protocol version: ""

kubelet

I created a tailoredprofile upon the code of this branch, which checks, that only TLS1.3 is enabled AND only TLS1.3 Ciphers are used.

kind: TailoredProfile
apiVersion: compliance.openshift.io/v1alpha1
metadata:
  name: conflict-tailoredprofile
  namespace: openshift-compliance
spec:
  description: Example of a tailoredProfile that extends OCP4 FedRAMP Moderate
  extends: upstream-ocp4-bsi-node
  setValues:
    - name: upstream-ocp4-var-kubelet-tls-cipher-suites
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: '"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384"'
    - name: upstream-ocp4-var-kubelet-tls-cipher-suites-regex
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: ^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384)$
    - name: upstream-ocp4-var-kubelet-tls-min-version
      rationale: CONFLICT TESTING
      value: VersionTLS13
    - name: upstream-ocp4-var-kubelet-tls-min-version-regex
      rationale: CONFLICT TESTING
      value: ^(?!VersionTLS10|VersionTLS11|VersionTLS12)
  title: conflict test
---
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: conflict-profile
  namespace: openshift-compliance
profiles:
  - apiGroup: compliance.openshift.io/v1alpha1
    kind: TailoredProfile
    name: conflict-tailoredprofile
settingsRef:
  apiGroup: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  name: default

The result were of course FAILS with the following remediations (x2 for compute and control):

spec:
  apply: false
  current:
    object:
      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      spec:
        kubeletConfig:
          tlsCipherSuites:
            - TLS_AES_128_GCM_SHA256
            - TLS_AES_256_GCM_SHA384

spec:
  apply: false
  current:
    object:
      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      spec:
        kubeletConfig:
          tlsMinVersion: VersionTLS13

I applied both of them and they are compatible with each other.

In this case the fields are two separate fields in the config.

Ingresscontroller

for Ingresscontroller I tried to solve it with the TLSProfiles.

so I modified the remediations in the code like:

---
# platform = multi_platform_ocp
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  tlsSecurityProfile:
    custom:
      minTLSVersion: VersionTLS13
    type: Custom
---
# platform = multi_platform_ocp
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  tlsSecurityProfile:
    custom:
      ciphers: [ {{ .var_ingresscontroller_tls_cipher_suites }} ]
    type: Custom

and hardcoded the tlsminversion in tls_version_check_router - value: "TLSv1.[3-9]{1}"

create tailoredprofile which demands TLS1.3 and special ciphers

kind: TailoredProfile
apiVersion: compliance.openshift.io/v1alpha1
metadata:
  name: ingress-tailoredprofile
  namespace: openshift-compliance
spec:
  description: Example of a tailoredProfile that extends OCP4 FedRAMP Moderate
  extends: upstream-ocp4-bsi
  enableRules:
    - name: upstream-ocp4-tls-version-check-router
      rationale: need to test this!
  setValues:
    - name: upstream-ocp4-var-ingresscontroller-tls-cipher-suites-regex
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: ^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384)$
    - name: upstream-ocp4-var-ingresscontroller-tls-cipher-suites
      rationale: KUBELET 2024-01-BSI-TR-02102-2
      value: '"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384"'
  title: conflict test
---
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: ingress-profile
  namespace: openshift-compliance
profiles:
  - apiGroup: compliance.openshift.io/v1alpha1
    kind: TailoredProfile
    name: ingress-tailoredprofile
settingsRef:
  apiGroup: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  name: default

this resulted in the following remediations

spec:
  apply: false
  current:
    object:
      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        tlsSecurityProfile:
          custom:
            ciphers:
              - TLS_AES_128_GCM_SHA256
              - TLS_AES_256_GCM_SHA384
          type: Custom
---
spec:
  apply: false
  current:
    object:
      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        tlsSecurityProfile:
          custom:
            minTLSVersion: VersionTLS13
          type: Custom

apply both remediations with the result in the default ingresscontroller

  tlsSecurityProfile:
    custom:
      ciphers:
        - TLS_AES_128_GCM_SHA256
        - TLS_AES_256_GCM_SHA384
      minTLSVersion: VersionTLS13
    type: Custom

obviously concurrent remediations work, as long as they do not overlap. (I did not test overlapping ones, but cannot think of good results).

Sep 24 '25 12:09 sluetze

/test

Oct 03 '25 13:10 rhmdnd

@rhmdnd: The /test command needs one or more targets. The following commands are available to trigger required jobs:

/test 4.12-e2e-aws-ocp4-cis

/test 4.12-e2e-aws-ocp4-cis-node

/test 4.12-e2e-aws-ocp4-e8

/test 4.12-e2e-aws-ocp4-high

/test 4.12-e2e-aws-ocp4-high-node

/test 4.12-e2e-aws-ocp4-moderate

/test 4.12-e2e-aws-ocp4-moderate-node

/test 4.12-e2e-aws-ocp4-pci-dss

/test 4.12-e2e-aws-ocp4-pci-dss-4-0

/test 4.12-e2e-aws-ocp4-pci-dss-node

/test 4.12-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.12-e2e-aws-ocp4-stig

/test 4.12-e2e-aws-ocp4-stig-node

/test 4.12-e2e-aws-rhcos4-e8

/test 4.12-e2e-aws-rhcos4-high

/test 4.12-e2e-aws-rhcos4-moderate

/test 4.12-e2e-aws-rhcos4-stig

/test 4.12-images

/test 4.14-e2e-aws-ocp4-bsi

/test 4.14-e2e-aws-ocp4-bsi-node

/test 4.14-e2e-aws-ocp4-pci-dss-4-0

/test 4.14-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.14-e2e-aws-rhcos4-bsi

/test 4.14-images

/test 4.16-e2e-aws-ocp4-bsi

/test 4.16-e2e-aws-ocp4-bsi-node

/test 4.16-e2e-aws-ocp4-cis

/test 4.16-e2e-aws-ocp4-cis-node

/test 4.16-e2e-aws-ocp4-e8

/test 4.16-e2e-aws-ocp4-high

/test 4.16-e2e-aws-ocp4-high-node

/test 4.16-e2e-aws-ocp4-moderate

/test 4.16-e2e-aws-ocp4-moderate-node

/test 4.16-e2e-aws-ocp4-pci-dss

/test 4.16-e2e-aws-ocp4-pci-dss-4-0

/test 4.16-e2e-aws-ocp4-pci-dss-node

/test 4.16-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.16-e2e-aws-ocp4-stig

/test 4.16-e2e-aws-ocp4-stig-node

/test 4.16-e2e-aws-rhcos4-bsi

/test 4.16-e2e-aws-rhcos4-e8

/test 4.16-e2e-aws-rhcos4-high

/test 4.16-e2e-aws-rhcos4-moderate

/test 4.16-e2e-aws-rhcos4-stig

/test 4.16-images

/test 4.17-e2e-aws-ocp4-bsi

/test 4.17-e2e-aws-ocp4-bsi-node

/test 4.17-e2e-aws-ocp4-cis

/test 4.17-e2e-aws-ocp4-cis-node

/test 4.17-e2e-aws-ocp4-e8

/test 4.17-e2e-aws-ocp4-high

/test 4.17-e2e-aws-ocp4-high-node

/test 4.17-e2e-aws-ocp4-moderate

/test 4.17-e2e-aws-ocp4-moderate-node

/test 4.17-e2e-aws-ocp4-pci-dss

/test 4.17-e2e-aws-ocp4-pci-dss-4-0

/test 4.17-e2e-aws-ocp4-pci-dss-node

/test 4.17-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.17-e2e-aws-ocp4-stig

/test 4.17-e2e-aws-ocp4-stig-node

/test 4.17-e2e-aws-rhcos4-bsi

/test 4.17-e2e-aws-rhcos4-e8

/test 4.17-e2e-aws-rhcos4-high

/test 4.17-e2e-aws-rhcos4-moderate

/test 4.17-e2e-aws-rhcos4-stig

/test 4.17-images

/test 4.18-e2e-aws-ocp4-bsi

/test 4.18-e2e-aws-ocp4-bsi-node

/test 4.18-e2e-aws-ocp4-cis

/test 4.18-e2e-aws-ocp4-cis-node

/test 4.18-e2e-aws-ocp4-e8

/test 4.18-e2e-aws-ocp4-high

/test 4.18-e2e-aws-ocp4-high-node

/test 4.18-e2e-aws-ocp4-moderate

/test 4.18-e2e-aws-ocp4-moderate-node

/test 4.18-e2e-aws-ocp4-pci-dss

/test 4.18-e2e-aws-ocp4-pci-dss-4-0

/test 4.18-e2e-aws-ocp4-pci-dss-node

/test 4.18-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.18-e2e-aws-ocp4-stig

/test 4.18-e2e-aws-ocp4-stig-node

/test 4.18-e2e-aws-rhcos4-bsi

/test 4.18-e2e-aws-rhcos4-e8

/test 4.18-e2e-aws-rhcos4-high

/test 4.18-e2e-aws-rhcos4-moderate

/test 4.18-e2e-aws-rhcos4-stig

/test 4.18-images

/test 4.19-e2e-aws-ocp4-bsi

/test 4.19-e2e-aws-ocp4-bsi-node

/test 4.19-e2e-aws-ocp4-cis

/test 4.19-e2e-aws-ocp4-cis-node

/test 4.19-e2e-aws-ocp4-e8

/test 4.19-e2e-aws-ocp4-high

/test 4.19-e2e-aws-ocp4-high-node

/test 4.19-e2e-aws-ocp4-moderate

/test 4.19-e2e-aws-ocp4-moderate-node

/test 4.19-e2e-aws-ocp4-pci-dss

/test 4.19-e2e-aws-ocp4-pci-dss-4-0

/test 4.19-e2e-aws-ocp4-pci-dss-node

/test 4.19-e2e-aws-ocp4-pci-dss-node-4-0

/test 4.19-e2e-aws-ocp4-stig

/test 4.19-e2e-aws-ocp4-stig-node

/test 4.19-e2e-aws-rhcos4-bsi

/test 4.19-e2e-aws-rhcos4-e8

/test 4.19-e2e-aws-rhcos4-high

/test 4.19-e2e-aws-rhcos4-moderate

/test 4.19-e2e-aws-rhcos4-stig

/test 4.19-e2e-rosa-ocp4-cis-node

/test 4.19-e2e-rosa-ocp4-pci-dss-node

/test 4.19-images

/test e2e-aws-ocp4-bsi

/test e2e-aws-ocp4-bsi-node

/test e2e-aws-ocp4-cis

/test e2e-aws-ocp4-cis-arm

/test e2e-aws-ocp4-cis-node

/test e2e-aws-ocp4-cis-node-arm

/test e2e-aws-ocp4-e8

/test e2e-aws-ocp4-high

/test e2e-aws-ocp4-high-node

/test e2e-aws-ocp4-moderate

/test e2e-aws-ocp4-moderate-arm

/test e2e-aws-ocp4-moderate-node

/test e2e-aws-ocp4-moderate-node-arm

/test e2e-aws-ocp4-pci-dss

/test e2e-aws-ocp4-pci-dss-4-0

/test e2e-aws-ocp4-pci-dss-node

/test e2e-aws-ocp4-pci-dss-node-4-0

/test e2e-aws-ocp4-stig

/test e2e-aws-ocp4-stig-node

/test e2e-aws-openshift-node-compliance

/test e2e-aws-openshift-platform-compliance

/test e2e-aws-rhcos4-bsi

/test e2e-aws-rhcos4-e8

/test e2e-aws-rhcos4-high

/test e2e-aws-rhcos4-moderate

/test e2e-aws-rhcos4-moderate-arm

/test e2e-aws-rhcos4-stig

/test images

Use /test all to run the following jobs that were automatically triggered:

pull-ci-ComplianceAsCode-content-master-4.12-images

pull-ci-ComplianceAsCode-content-master-4.14-images

pull-ci-ComplianceAsCode-content-master-4.16-images

pull-ci-ComplianceAsCode-content-master-4.17-images

pull-ci-ComplianceAsCode-content-master-4.18-images

pull-ci-ComplianceAsCode-content-master-4.19-images

pull-ci-ComplianceAsCode-content-master-e2e-aws-openshift-node-compliance

pull-ci-ComplianceAsCode-content-master-e2e-aws-openshift-platform-compliance

pull-ci-ComplianceAsCode-content-master-images

In response to this:

/test

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.

Oct 03 '25 13:10 openshift-ci[bot]

/test 4.19-e2e-aws-ocp4-pci-dss

Oct 03 '25 13:10 rhmdnd

/test 4.19-e2e-aws-ocp4-bsi

Oct 03 '25 13:10 rhmdnd

/test 4.12-e2e-aws-ocp4-pci-dss /test 4.14-e2e-aws-ocp4-bsi

Testing against some older clusters to see what those rules do with potentially different defaults.

Oct 03 '25 13:10 rhmdnd

@sluetze: The following test 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/4.12-e2e-aws-ocp4-pci-dss	9b1071a43d73839877f356d7408368b10580dc66	link	true	`/test 4.12-e2e-aws-ocp4-pci-dss`

Full PR test history. Your PR dashboard.

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.

Oct 03 '25 14:10 openshift-ci[bot]

@rhmdnd

as requested, I made minTLSVersion configurable for the checks and the remediation. The variables are once per component (ingresscontroller, apiserver, kubelet) and used consistently in the rules and remediations. The remediations of cipher and minTLSVersion are the same, some are triple due to old rules under "general".

I refrained from removing the "old rules" for the moment, as this PR is big enough already.

I made some adjustments to the description of the variables to provide information about incompatibilities of specific combinations of minTLSVersion and cipher lists, since the components do currently not behave as consistently as one might expect. I addressed this to the pqc folks to have improvements in later versions.

Nov 25 '25 11:11 sluetze

[RFE-6859] Configurable cipher suites

Description:

Rationale:

Review Hints:

conclusion

long version

removing minTLSVersion

kubelet

Ingresscontroller