- Notifications
You must be signed in to change notification settings - Fork756
[RFE-6859] Configurable cipher suites#13866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Conversation
Hi@sluetze. Thanks for your PR. I'm waiting for aComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listedhere. Instructions for interacting with me using PR comments are availablehere. If you have questions or suggestions related to my behavior, please file an issue against thekubernetes-sigs/prow repository. |
ba1ccd4 to9b1071aCompare| type:Custom | ||
| custom: | ||
| ciphers:[ {{ .var_apiserver_tls_cipher_suites }} ] | ||
| minTLSVersion:VersionTLS12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I wonder if we should parameterize this, too? I'm thinking about cases where someone might want to force the cluster to use PQC-safe algorithms only available through TLS 1.3.
| -TLS_AES_256_GCM_SHA384 | ||
| -TLS_CHACHA20_POLY1305_SHA256 | ||
| ciphers:[ {{ .var_ingresscontroller_tls_cipher_suites }} ] | ||
| minTLSVersion:VersionTLS12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Similar comment here... Or, if we should consider a master switch for all min TLS versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
sluetze commentedSep 24, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
conclusionWe cannot remove the minTLSVersion option, as it is needed to apply the remediation. 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 that being said, I can create variables for the minTLSVersion, but for this I would also:
rationale: risk: renaming the rules of course might break tailoredprofiles which exclude or include these rules. long versionOh no a rabbit-hole :( There are separate rules for minTLSVersion
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 minTLSVersionthis seems to not be a good option. kubeletI 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:TailoredProfileapiVersion:compliance.openshift.io/v1alpha1metadata:name:conflict-tailoredprofilenamespace:openshift-compliancespec:description:Example of a tailoredProfile that extends OCP4 FedRAMP Moderateextends:upstream-ocp4-bsi-nodesetValues: -name:upstream-ocp4-var-kubelet-tls-cipher-suitesrationale:KUBELET 2024-01-BSI-TR-02102-2value:'"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384"' -name:upstream-ocp4-var-kubelet-tls-cipher-suites-regexrationale:KUBELET 2024-01-BSI-TR-02102-2value:^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384)$ -name:upstream-ocp4-var-kubelet-tls-min-versionrationale:CONFLICT TESTINGvalue:VersionTLS13 -name:upstream-ocp4-var-kubelet-tls-min-version-regexrationale:CONFLICT TESTINGvalue:^(?!VersionTLS10|VersionTLS11|VersionTLS12)title:conflict test---apiVersion:compliance.openshift.io/v1alpha1kind:ScanSettingBindingmetadata:name:conflict-profilenamespace:openshift-complianceprofiles: -apiGroup:compliance.openshift.io/v1alpha1kind:TailoredProfilename:conflict-tailoredprofilesettingsRef:apiGroup:compliance.openshift.io/v1alpha1kind:ScanSettingname:default The result were of course FAILS with the following remediations (x2 for compute and control): spec:apply:falsecurrent:object:apiVersion:machineconfiguration.openshift.io/v1kind:KubeletConfigspec:kubeletConfig:tlsCipherSuites: -TLS_AES_128_GCM_SHA256 -TLS_AES_256_GCM_SHA384 spec:apply:falsecurrent:object:apiVersion:machineconfiguration.openshift.io/v1kind:KubeletConfigspec: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. Ingresscontrollerfor Ingresscontroller I tried to solve it with the TLSProfiles. so I modified the remediations in the code like: ---# platform = multi_platform_ocpapiVersion:operator.openshift.io/v1kind:IngressControllermetadata:name:defaultnamespace:openshift-ingress-operatorspec:tlsSecurityProfile:custom:minTLSVersion:VersionTLS13type:Custom---# platform = multi_platform_ocpapiVersion:operator.openshift.io/v1kind:IngressControllermetadata:name:defaultnamespace:openshift-ingress-operatorspec:tlsSecurityProfile:custom:ciphers:[ {{ .var_ingresscontroller_tls_cipher_suites }} ]type:Custom and hardcoded the tlsminversion in create tailoredprofile which demands TLS1.3 and special ciphers kind:TailoredProfileapiVersion:compliance.openshift.io/v1alpha1metadata:name:ingress-tailoredprofilenamespace:openshift-compliancespec:description:Example of a tailoredProfile that extends OCP4 FedRAMP Moderateextends:upstream-ocp4-bsienableRules: -name:upstream-ocp4-tls-version-check-routerrationale:need to test this!setValues: -name:upstream-ocp4-var-ingresscontroller-tls-cipher-suites-regexrationale:KUBELET 2024-01-BSI-TR-02102-2value:^(TLS_AES_128_GCM_SHA256|TLS_AES_256_GCM_SHA384)$ -name:upstream-ocp4-var-ingresscontroller-tls-cipher-suitesrationale:KUBELET 2024-01-BSI-TR-02102-2value:'"TLS_AES_128_GCM_SHA256","TLS_AES_256_GCM_SHA384"'title:conflict test---apiVersion:compliance.openshift.io/v1alpha1kind:ScanSettingBindingmetadata:name:ingress-profilenamespace:openshift-complianceprofiles: -apiGroup:compliance.openshift.io/v1alpha1kind:TailoredProfilename:ingress-tailoredprofilesettingsRef:apiGroup:compliance.openshift.io/v1alpha1kind:ScanSettingname:default this resulted in the following remediations spec:apply:falsecurrent:object:apiVersion:operator.openshift.io/v1kind:IngressControllermetadata:name:defaultnamespace:openshift-ingress-operatorspec:tlsSecurityProfile:custom:ciphers: -TLS_AES_128_GCM_SHA256 -TLS_AES_256_GCM_SHA384type:Custom---spec:apply:falsecurrent:object:apiVersion:operator.openshift.io/v1kind:IngressControllermetadata:name:defaultnamespace:openshift-ingress-operatorspec:tlsSecurityProfile:custom:minTLSVersion:VersionTLS13type:Custom apply both remediations with the result in the default ingresscontroller tlsSecurityProfile:custom:ciphers: -TLS_AES_128_GCM_SHA256 -TLS_AES_256_GCM_SHA384minTLSVersion:VersionTLS13type:Custom obviously concurrent remediations work, as long as they do not overlap. (I did not test overlapping ones, but cannot think of good results). |
/test |
@rhmdnd: The Use In response tothis:
Instructions for interacting with me using PR comments are availablehere. If you have questions or suggestions related to my behavior, please file an issue against thekubernetes-sigs/prow repository. |
/test 4.19-e2e-aws-ocp4-pci-dss |
/test 4.19-e2e-aws-ocp4-bsi |
/test 4.12-e2e-aws-ocp4-pci-dss Testing against some older clusters to see what those rules do with potentially different defaults. |
@sluetze: The following testfailed, say
Full PR test history.Your PR dashboard. Instructions for interacting with me using PR comments are availablehere. If you have questions or suggestions related to my behavior, please file an issue against thekubernetes-sigs/prow repository. I understand the commands that are listedhere. |
Uh oh!
There was an error while loading.Please reload this page.
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
Fixeshttps://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
etcd:
apiserver:
oc get apiserver cluster -oyamldoes not provide the same output asoc 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 rejectedingresscontroller:
This are the result tables, of my manual tests:
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: