Skip to content

Add support for TLS curves in TLSProfile #2583

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
davidesalerno wants to merge 1 commit into
base: master
Choose a base branch
from
+20,839 −2
Open

Add support for TLS curves in TLSProfile #2583

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions config/v1/types_tlssecurityprofile.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,31 @@ const (
TLSProfileCustomType TLSProfileType = "Custom"
)

// TLSCurve is a named curve identifier that can be used in TLSProfile.Curves.
// There is a one-to-one mapping between these names and the curve IDs defined
// in crypto/tls package based on IANA's "TLS Supported Groups" registry:
// https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
Copy link

@kannon92 kannon92 Dec 16, 2025

Choose a reason for hiding this comment

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

Looking at cryto/tls, I see the following values.

type CurveID uint16

const (
	CurveP256          CurveID = 23
	CurveP384          CurveID = 24
	CurveP521          CurveID = 25
	X25519             CurveID = 29
	X25519MLKEM768     CurveID = 4588
	SecP256r1MLKEM768  CurveID = 4587
	SecP384r1MLKEM1024 CurveID = 4589
)

Why are we not including all the values?

Copy link

@kannon92 kannon92 Dec 16, 2025

Choose a reason for hiding this comment

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

ref: https://github.com/golang/go/blob/master/src/crypto/tls/common.go#L145

Copy link
Author

@davidesalerno davidesalerno Dec 22, 2025

Choose a reason for hiding this comment

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

Ok so I think we can align to those values the available curve supported

//
// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768
type TLSCurve string
Comment on lines +165 to +166
Copy link

@coderabbitai coderabbitai bot Jan 13, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Kubebuilder enum missing two defined constants.

The +kubebuilder:validation:Enum annotation only includes 5 curves, but constants TLSCurveP256r1MLKEM768 and TLSCurveP384r1MLKEM1024 are defined below. If these curves are intended to be valid, add them to the enum. Otherwise, consider removing the unused constants.

🔧 Proposed fix (if all curves should be valid) 
-// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768
+// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768;P256r1MLKEM768;P384r1MLKEM1024
 type TLSCurve string
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768
type TLSCurve string
// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768;P256r1MLKEM768;P384r1MLKEM1024
type TLSCurve string
🤖 Prompt for AI Agents 
In @config/v1/types_tlssecurityprofile.go around lines 165 - 166, The
kubebuilder Enum on type TLSCurve is missing the constants
TLSCurveP256r1MLKEM768 and TLSCurveP384r1MLKEM1024; either add those two names
to the +kubebuilder:validation:Enum list for TLSCurve so the CRD validates them,
or remove the unused constants TLSCurveP256r1MLKEM768 and
TLSCurveP384r1MLKEM1024 if they are not intended to be valid values; update the
annotation next to type TLSCurve and ensure the constant names match exactly.


const (
// TLSCurveX25519 represents X25519.
TLSCurveX25519 TLSCurve = "X25519"
// TLSCurveP256 represents P-256 (secp256r1).
TLSCurveP256 TLSCurve = "P-256"
// TLSCurveP384 represents P-384 (secp384r1).
TLSCurveP384 TLSCurve = "P-384"
// TLSCurveP521 represents P-521 (secp521r1).
TLSCurveP521 TLSCurve = "P-521"
// TLSCurveX25519MLKEM768 represents X25519MLKEM768.
TLSCurveX25519MLKEM768 TLSCurve = "X25519MLKEM768"
// TLSCurveP256r1MLKEM1024 represents P256r1MLKEM1024 (secp256r1MLKEM1024).
TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
Comment on lines +179 to +180
Copy link

@coderabbitai coderabbitai bot Dec 22, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Comment typo: says "MLKEM1024" but constant is "MLKEM768".

The comment states P256r1MLKEM1024 but the constant name and value use P256r1MLKEM768.

🔎 Proposed fix 
-	// TLSCurveP256r1MLKEM1024 represents P256r1MLKEM1024 (secp256r1MLKEM1024).
+	// TLSCurveP256r1MLKEM768 represents P256r1MLKEM768 (secp256r1MLKEM768).
 	TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// TLSCurveP256r1MLKEM1024 represents P256r1MLKEM1024 (secp256r1MLKEM1024).
TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
// TLSCurveP256r1MLKEM768 represents P256r1MLKEM768 (secp256r1MLKEM768).
TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
🤖 Prompt for AI Agents 
In config/v1/types_tlssecurityprofile.go around lines 224-225, the comment for
the TLSCurve constant mismatches the constant name/value: it says
"P256r1MLKEM1024" while the constant is named and set to "P256r1MLKEM768";
update the comment to correctly state "P256r1MLKEM768" so it matches the
constant name and value, keeping the descriptive text consistent (e.g.,
"TLSCurveP256r1MLKEM768 represents P256r1MLKEM768 (secp256r1MLKEM768)").

Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Good bot.

I'm unclear as to which this constant is supposed to actually represent

Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Also, this value doesn't seem to be represented in the allowed values based on the enum marker.

Copy link

@coderabbitai coderabbitai bot Jan 12, 2026

Choose a reason for hiding this comment

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

@everettraven You're absolutely correct! 🎯

Both of the new post-quantum cryptography (PQC) curve constants are missing from the enum validation marker:

  • P256r1MLKEM768 (constant name has MLKEM768, but comment incorrectly says MLKEM1024)
  • P384r1MLKEM1024

The current enum marker on line 210:

// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768

Should be updated to include both new curves:

// +kubebuilder:validation:Enum=X25519;P-256;P-384;P-521;X25519MLKEM768;P256r1MLKEM768;P384r1MLKEM1024

Without this fix, Kubernetes CRD validation will reject any attempts to use these new PQC curves, even though the constants are defined. This needs to be corrected before merge.

Copy link

@coderabbitai coderabbitai bot Jan 12, 2026

Choose a reason for hiding this comment

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

🧩 Analysis chain

@everettraven You've identified an important issue! The TLSCurveP256r1MLKEM768 and TLSCurveP384r1MLKEM1024 constants are indeed missing from the kubebuilder validation enum. Let me search the codebase to understand the intended usage.

🏁 Script executed:

#!/bin/bash
# Search for usage of P256r1MLKEM768 and P384r1MLKEM1024 constants
echo "=== Searching for P256r1MLKEM768 usage ==="
rg -n 'P256r1MLKEM768' --type go

echo -e "\n=== Searching for P384r1MLKEM1024 usage ==="
rg -n 'P384r1MLKEM1024' --type go

echo -e "\n=== Check CRD enum values ==="
rg -n 'Enum=.*MLKEM' --type yaml

echo -e "\n=== Check if these are referenced in documentation/comments ==="
rg -n 'SecP256r1MLKEM|SecP384r1MLKEM' --type go --type yaml

Length of output: 10645

Based on the search results, I found multiple inconsistencies that need clarification from @davidesalerno:

Issues Found:

  1. Constant definitions vs enum validation mismatch:

    • Constants defined: P256r1MLKEM768 and P384r1MLKEM1024
    • Enum validation only includes: X25519, P-256, P-384, P-521, X25519MLKEM768
    • Neither P256r1 nor P384r1 variants are in the enum, making them unusable

  2. Documentation vs constant naming mismatch:

    • Documentation references: SecP256r1MLKEM1024 and SecP384r1MLKEM1024
    • Constants are named: P256r1MLKEM768 and P384r1MLKEM1024
    • Note the "SecP" prefix difference and number differences

  3. Comment typo:

    • Line 224 comment says P256r1MLKEM1024 but constant name/value is P256r1MLKEM768

  4. Documentation claims these are defaults, but they're not:

    • Docs say: "TLSProfiles Old, Intermediate, Modern are including by default the following curves: X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024, SecP384r1MLKEM1024"
    • Actual default profiles only include: X25519, P-256, P-384, X25519MLKEM768

Questions for @davidesalerno:

  1. Should these PQC hybrid curves (P256r1MLKEM768 and P384r1MLKEM1024) be added to the enum validation, or should they be removed from the constants?
  2. What are the correct names: P256r1 or SecP256r1?
  3. What are the correct MLKEM variants: 768 or 1024 for P256r1?
  4. Should these be included in the default TLS profiles?

Without these constants being in the enum, users cannot actually use them even though they're defined in the code.

🧬 Code Graph Analysis Results

[config/v1/zz_generated.swagger_doc_generated.go:2867-2869]
func (OldTLSProfile) SwaggerDoc() map[string]string {
return map_OldTLSProfile
}

[config/v1/zz_generated.swagger_doc_generated.go:2851-2853]
func (IntermediateTLSProfile) SwaggerDoc() map[string]string {
return map_IntermediateTLSProfile
}

[config/v1/zz_generated.swagger_doc_generated.go:2859-2861]
func (ModernTLSProfile) SwaggerDoc() map[string]string {
return map_ModernTLSProfile
}

[config/v1/zz_generated.swagger_doc_generated.go:2843-2845]
func (CustomTLSProfile) SwaggerDoc() map[string]string {
return map_CustomTLSProfile
}

[config/v1/zz_generated.swagger_doc_generated.go:2878-2880]
func (TLSProfileSpec) SwaggerDoc() map[string]string {
return map_TLSProfileSpec
}

Comment on lines +179 to +180
Copy link

@coderabbitai coderabbitai bot Jan 13, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Comment/constant name mismatch.

The comment says "P256r1MLKEM1024" but the constant value is "P256r1MLKEM768". This appears to be a copy-paste error.

🔧 Proposed fix 
-	// TLSCurveP256r1MLKEM1024 represents P256r1MLKEM1024 (secp256r1MLKEM1024).
+	// TLSCurveP256r1MLKEM768 represents P256r1MLKEM768 (secp256r1MLKEM768).
 	TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// TLSCurveP256r1MLKEM1024 represents P256r1MLKEM1024 (secp256r1MLKEM1024).
TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
// TLSCurveP256r1MLKEM768 represents P256r1MLKEM768 (secp256r1MLKEM768).
TLSCurveP256r1MLKEM768 TLSCurve = "P256r1MLKEM768"
🤖 Prompt for AI Agents 
In @config/v1/types_tlssecurityprofile.go around lines 179 - 180, The comment
for TLSCurveP256r1MLKEM768 is incorrect (it references P256r1MLKEM1024); update
the comment to match the constant and value by replacing "P256r1MLKEM1024" with
"P256r1MLKEM768" so the doc comment for TLSCurveP256r1MLKEM768 accurately
reflects the constant string "P256r1MLKEM768".

// TLSCurveP384r1MLKEM1024 represents P384r1MLKEM1024 (secp384r1MLKEM1024).
TLSCurveP384r1MLKEM1024 TLSCurve = "P384r1MLKEM1024"
)
Comment on lines +165 to +183
Copy link

@coderabbitai coderabbitai bot Dec 22, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n config/v1/types_tlssecurityprofile.go | sed -n '210,228p'

Repository: openshift/api

Length of output: 973

🏁 Script executed:

# Check the exact kubebuilder annotation
rg -n "kubebuilder:validation:Enum" config/v1/types_tlssecurityprofile.go -A 1

# Check all TLSCurve constants
rg -n "TLSCurve\w+\s+TLSCurve\s*=" config/v1/types_tlssecurityprofile.go -B 1

Repository: openshift/api

Length of output: 1120

🏁 Script executed:

# Check if P256r1MLKEM768 and P384r1MLKEM1024 are used elsewhere
rg "P256r1MLKEM768|P384r1MLKEM1024" --type go -i

Repository: openshift/api

Length of output: 3577

Add P256r1MLKEM768 and P384r1MLKEM1024 to the kubebuilder enum validation.

The constants TLSCurveP256r1MLKEM768 and TLSCurveP384r1MLKEM1024 are defined at lines 225 and 227, but the kubebuilder validation enum at line 210 only allows X25519;P-256;P-384;P-521;X25519MLKEM768. These curves cannot be configured via the API since they fail CRD validation. Documentation indicates these curves should be available for TLS profiles, so they must be added to the enum.

🤖 Prompt for AI Agents 
In config/v1/types_tlssecurityprofile.go around lines 210 to 228, the
kubebuilder validation enum on the TLSCurve type doesn't include the newly
defined constants TLSCurveP256r1MLKEM768 and TLSCurveP384r1MLKEM1024, preventing
those values from being accepted by CRD validation; update the kubebuilder tag
on the TLSCurve type to include "P256r1MLKEM768" and "P384r1MLKEM1024" (matching
the constant string values) so the CRD allows those curve names, then regenerate
CRDs if applicable.

Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Good bot.

This needs addressing.

Copy link

@coderabbitai coderabbitai bot Jan 12, 2026

Choose a reason for hiding this comment

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

@everettraven Thank you for confirming! I'll plan the fix to add the missing curves to the validation enum.

[plan_code_changes]

Task: Add missing TLS curves to kubebuilder enum validation

  • Update the kubebuilder enum annotation on the TLSCurve type to include P256r1MLKEM768 and P384r1MLKEM1024
  • This will allow these curves to pass CRD validation and be configurable via the API


// TLSProfileSpec is the desired behavior of a TLSSecurityProfile.
type TLSProfileSpec struct {
// ciphers is used to specify the cipher algorithms that are negotiated
Expand All @@ -168,6 +193,38 @@ type TLSProfileSpec struct {
//
// +listType=atomic
Ciphers []string `json:"ciphers"`
// curves is used to specify the elliptic curves that are used during
// the TLS handshake. Operators may remove entries their operands do
// not support.
Comment on lines +196 to +198
Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Suggested change
// curves is used to specify the elliptic curves that are used during
// the TLS handshake. Operators may remove entries their operands do
// not support.
// curves is an optional field used to specify the elliptic curves that are used during
// the TLS handshake. Operators may remove entries their operands do
// not support.

//
// TLSProfiles Old, Intermediate, Modern are including by default the following
// curves: X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024, SecP384r1MLKEM1024.
Comment on lines +200 to +201
Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

I would probably specify this information on the actual profiles themselves like is done for the existing ciphers field.

This keeps documentation location consistent and omits what seems like an unnecessary reference to a higher-order field.

Comment on lines +200 to +201
Copy link

@coderabbitai coderabbitai bot Jan 13, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Documentation doesn't match actual defaults.

The comment states that default profiles include "SecP256r1MLKEM1024, SecP384r1MLKEM1024", but the actual default curve lists (lines 301-306, 323-328, 337-342) only include: X25519, P-256, P-384, X25519MLKEM768.

Either update the documentation to match the actual defaults, or add the missing curves to the default profiles.

🔧 Proposed fix for documentation 
-	// TLSProfiles Old, Intermediate, Modern are including by default the following
-	// curves: X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024, SecP384r1MLKEM1024.
+	// TLSProfiles Old, Intermediate, Modern are including by default the following
+	// curves: X25519, P-256, P-384, X25519MLKEM768.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// TLSProfiles Old, Intermediate, Modern are including by default the following
// curves: X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024, SecP384r1MLKEM1024.
// TLSProfiles Old, Intermediate, Modern are including by default the following
// curves: X25519, P-256, P-384, X25519MLKEM768.

// TLSProfiles Custom do not include any curves by default.
Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Same comment as above, this seems better suited to the higher-order field documentation.

// NOTE: since this field is optional, if no curves are specified, the default curves
// used by the underlying TLS library will be used.
Comment on lines +203 to +204
Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

What do you think of saying something like:

When omitted, this means no opinion and the platform is left to choose reasonable defaults which are subject to change over time and may be different per platform component depending on the underlying TLS libraries they use.

It generally follows our more standard "omission means no opinion" for configuration APIs while clearing stating that the default behavior depends on the underlying implementation per-component.

//
// For example, to use X25519 and P-256 (yaml):
//
// # Example: Force PQC-only encryption
// apiVersion: config.openshift.io/v1
// kind: APIServer
// spec:
// tlsSecurityProfile:
// type: Custom
// custom:
// ciphers:
// - TLS_AES_128_GCM_SHA256
// - TLS_AES_256_GCM_SHA384
// - TLS_CHACHA20_POLY1305_SHA256
// curves:
// - X25519MLKEM768 # PQC-only: only hybrid quantum-resistant curve
// minTLSVersion: VersionTLS13
Comment on lines +208 to +221
Copy link
Contributor

@Miciah Miciah Dec 1, 2025

Choose a reason for hiding this comment

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

Does this render all right in the oc explain output?

Copy link
Contributor

@yuqi-zhang yuqi-zhang Dec 4, 2025

Choose a reason for hiding this comment

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

Good question, we generally don't have cross-field examples, but I guess in this case, you cannot specify arbitrary curves that the ciphers you have don't support?

Would anything validate that the curves list is correct for the ciphers you have? Or are all curves supported by all ciphers? Would there ever be a need to say, specify a subset of curves per cipher?

(This might be completely invalid, but as an example, you would want X25519MLKEM768 for TLS_CHACHA20_POLY1305_SHA256, and P-384 for TLS_AES_256_GCM_SHA384, and only those combinations)

Copy link

@richardsonnick richardsonnick Dec 4, 2025

Choose a reason for hiding this comment

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

IMO the user facing docs call out that the custom TLS profile "can cause some problems" if misconfigured which is a good hint to the administrator that they should:

  1. Know what they are doing
  2. Validate their config before using the profile in a production environment

I think the best approach here is to offer reasonable valid defaults while keeping custom profiles as a "power user" option.

Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Maybe the example is better suited to the higher-order custom field since it is showing a more holistic configuration example?

//
// +optional
Copy link
Contributor

@yuqi-zhang yuqi-zhang Nov 20, 2025

Choose a reason for hiding this comment

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

optional fields should have godoc around what happens if the field is not set (i.e. what is the default behaviour)

Copy link
Author

@davidesalerno davidesalerno Nov 27, 2025

Choose a reason for hiding this comment

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

I added a note to address this case. What do you think?

Copy link
Contributor

@yuqi-zhang yuqi-zhang Dec 4, 2025

Choose a reason for hiding this comment

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

Technically you don't need the NOTE: since this field is optional, in the godoc, since it will be explained as an optional field, but up to you if you want to highlight that. Otherwise looks fine to me

// +listType=set
// +kubebuilder:validation:MaxItems=5
// +openshift:enable:FeatureGate=TLSCurvesConfiguration
Curves []TLSCurve `json:"curves,omitempty"`
Copy link
Contributor

@everettraven everettraven Jan 12, 2026

Choose a reason for hiding this comment

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

Would there be any difference in setting this to curves: [] and omitting the field altogether?

// minTLSVersion is used to specify the minimal version of the TLS protocol
// that is negotiated during the TLS handshake. For example, to use TLS
// versions 1.1, 1.2 and 1.3 (yaml):
Expand Down Expand Up @@ -241,6 +298,12 @@ var TLSProfiles = map[TLSProfileType]*TLSProfileSpec{
"AES256-SHA",
"DES-CBC3-SHA",
},
Curves: []TLSCurve{
TLSCurveX25519,
TLSCurveP256,
TLSCurveP384,
TLSCurveX25519MLKEM768,
},
MinTLSVersion: VersionTLS10,
},
TLSProfileIntermediateType: {
Expand All @@ -257,6 +320,12 @@ var TLSProfiles = map[TLSProfileType]*TLSProfileSpec{
"DHE-RSA-AES128-GCM-SHA256",
"DHE-RSA-AES256-GCM-SHA384",
},
Curves: []TLSCurve{
TLSCurveX25519,
TLSCurveP256,
TLSCurveP384,
TLSCurveX25519MLKEM768,
},
MinTLSVersion: VersionTLS12,
},
TLSProfileModernType: {
Expand All @@ -265,6 +334,12 @@ var TLSProfiles = map[TLSProfileType]*TLSProfileSpec{
"TLS_AES_256_GCM_SHA384",
"TLS_CHACHA20_POLY1305_SHA256",
},
Curves: []TLSCurve{
TLSCurveX25519,
TLSCurveP256,
TLSCurveP384,
TLSCurveX25519MLKEM768,
},
MinTLSVersion: VersionTLS13,
},
}
33 changes: 33 additions & 0 deletions ...zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -325,6 +325,39 @@ spec:
type: string
type: array
x-kubernetes-list-type: atomic
curves:
description: "curves is used to specify the elliptic curves
that are used during\nthe TLS handshake. Operators may
remove entries their operands do\nnot support.\n\nTLSProfiles
Old, Intermediate, Modern are including by default the following\ncurves:
X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024,
SecP384r1MLKEM1024.\nTLSProfiles Custom do not include any
curves by default.\nNOTE: since this field is optional,
if no curves are specified, the default curves\nused by
the underlying TLS library will be used.\n\nFor example,
to use X25519 and P-256 (yaml):\n\n# Example: Force PQC-only
encryption\napiVersion: config.openshift.io/v1\nkind: APIServer\nspec:\n
\ tlsSecurityProfile:\n type: Custom\n custom:\n ciphers:\n\t
\ - TLS_AES_128_GCM_SHA256\n - TLS_AES_256_GCM_SHA384\n
\ - TLS_CHACHA20_POLY1305_SHA256\n curves:\n
\ - X25519MLKEM768 # PQC-only: only hybrid quantum-resistant
curve\n minTLSVersion: VersionTLS13"
items:
description: |-
TLSCurve is a named curve identifier that can be used in TLSProfile.Curves.
There is a one-to-one mapping between these names and the curve IDs defined
in crypto/tls package based on IANA's "TLS Supported Groups" registry:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
enum:
- X25519
- P-256
- P-384
- P-521
- X25519MLKEM768
type: string
maxItems: 5
type: array
x-kubernetes-list-type: set
Comment on lines +328 to +360
Copy link

@coderabbitai coderabbitai bot Dec 22, 2025

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Mismatch between description and enum values for curves

The description states that Old/Intermediate/Modern profiles include 7 curves by default:

X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM1024, SecP384r1MLKEM1024

However, the enum (lines 356-361) only defines 5 values:

  • X25519, P-256, P-384, P-521, X25519MLKEM768

Missing from enum: SecP256r1MLKEM1024, SecP384r1MLKEM1024

Additionally, maxItems: 5 (line 363) would prevent users from specifying all 7 curves mentioned in the description.

Please either update the enum and maxItems to include all mentioned curves, or correct the description to match the actual supported values.

🤖 Prompt for AI Agents 
In
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
around lines 333-365, the `curves` description lists 7 curves but the enum only
defines 5 and maxItems is 5; update the enum to include SecP256r1MLKEM1024 and
SecP384r1MLKEM1024 and change maxItems to 7 so the schema matches the
description (alternatively, if those two curves are not supported, edit the
descriptive text to list only the five supported curves and keep maxItems at 5).
Ensure the enum entries exactly match the names in the description and adjust
maxItems accordingly.

minTLSVersion:
description: |-
minTLSVersion is used to specify the minimal version of the TLS protocol
Expand Down
5 changes: 5 additions & 0 deletions config/v1/zz_generated.deepcopy.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

1 change: 1 addition & 0 deletions config/v1/zz_generated.featuregated-crd-manifests.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ apiservers.config.openshift.io:
Category: ""
FeatureGates:
- KMSEncryptionProvider
- TLSCurvesConfiguration
FilenameOperatorName: config-operator
FilenameOperatorOrdering: "01"
FilenameRunLevel: "0000_10"
Expand Down
Loading