OCPSTRAT-3499: Enhancement for custom default ingress certificate in HyperShift - #2074
Conversation
…HyperShift Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
openshift-ci-robot
added
the
jira/valid-reference
|
@redhat-chai-bot: This pull request references OCPSTRAT-3499 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 feature to target either version "5.0." or "openshift-5.0.", but it targets "openshift-5.1" instead. DetailsIn response to this:
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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
WalkthroughThe enhancement proposal defines an optional ChangesHyperShift ingress certificate
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md`:
- Around line 445-448: Clarify the removal transition for defaultCertificate in
the documented behavior: when it becomes nil, stop custom certificate
synchronization, remove or replace the intermediate Secret, restore
CPO-generated wildcard data, and update the guest Secret. Extend the E2E
coverage to verify both source Secret deletion and downgrade from a custom
certificate, ensuring the previous custom certificate is not retained.
- Around line 583-587: Update the Secret verification commands in the source,
control-plane, and guest-cluster procedures to avoid printing `.data` values,
especially `tls.key`. Inspect only Secret metadata and the presence of
`tls.crt`/`tls.key` keys, and decode or display certificate content only when
needed; apply the same safe pattern to all referenced command blocks.
- Around line 339-342: Update the ManagedCA Observer behavior described in the
“Observability via CA Observer” section so observed-default-ingress-cert
contains only public certificate or CA data and never copies tls.key or other
source Secret contents. Add an E2E assertion verifying tls.key is absent from
the observed ConfigMap, while preserving propagation of the intended public
data.
- Around line 574-576: The documentation should specify that certificate
synchronization failures update HostedCluster status with an
IngressCertificateSynced=False condition when the source Secret is missing or
malformed, while preserving the existing certificate. State that this condition
is cleared only after the target Secret is successfully updated, so the active
certificate state is distinguishable from the requested state.
- Around line 131-137: The proposal must define how
HostedControlPlane.defaultCertificate is resolved relative to its owning
HostedCluster, including whether it is accepted through the HostedCluster,
rejected, or only supported on HostedCluster. Update the API conversion and
reconciliation behavior accordingly, and add an E2E case covering the selected
behavior and source-secret namespace resolution.
- Around line 216-225: Expand the rotation procedure to document the watch,
index, and resync path that maps updates and deletions of the Secret referenced
by defaultCertificate to the owning HostedCluster queue, without requiring a
HostedCluster specification change. Add a rotation test covering an update that
changes only tls.crt and tls.key, and verify the new certificate propagates
through the control plane and guest cluster.
- Around line 139-150: Expand the implementation details to define the two-hop
certificate contract: specify the control-plane intermediate Secret
name/namespace, required labels, and ownership metadata recognized by HCCO;
state that validated custom tls.crt and tls.key data takes precedence over
ingress-crt; and document the reconciliation guard or ownership mechanism that
prevents other reconcilers from overwriting default-ingress-cert.
- Around line 262-265: Align the DefaultCertificate API declaration and
documentation: either add the claimed omitzero serialization tag and update
compatibility validation to model older CRD pruning, or remove the omitzero and
N-1 compatibility claims. Ensure the documented upgrade behavior matches the
actual declaration and validation approach.
- Around line 251-259: Update IngressDefaultCertificateReference.Name with the
Kubernetes DNS-subdomain validation pattern in addition to its existing length
constraints, rejecting names such as my_secret, My-Certificate, -secret, and
my-secret. Add validation tests covering these invalid values.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: f8bf49ff-3cf3-4146-a8fa-13a33b3ceadf
📒 Files selected for processing (1)
enhancements/hypershift/hypershift-ingress-default-certificate.md
| // IngressDefaultCertificateReference references a TLS Secret by name. | ||
| type IngressDefaultCertificateReference struct { | ||
| // name is the name of a kubernetes.io/tls Secret in the HostedCluster | ||
| // namespace. The Secret must contain tls.crt and tls.key entries. | ||
| // +kubebuilder:validation:Required | ||
| // +kubebuilder:validation:MinLength=1 | ||
| // +kubebuilder:validation:MaxLength=253 | ||
| Name string `json:"name"` | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 5 'validation:Pattern|MaxLength=253|LocalObjectReference|Secret.*Reference' --glob '*.go'Repository: openshift/enhancements
Length of output: 160
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== candidate file =="
if [ -f enhancements/hypershift/hypershift-ingress-default-certificate.md ]; then
wc -l enhancements/hypershift/hypershift-ingress-default-certificate.md
sed -n '220,280p' enhancements/hypershift/hypershift-ingress-default-certificate.md | nl -ba -v220
else
echo "candidate file missing"
git ls-files | sed -n '1,120p'
fi
echo "== git diff/stat context =="
git diff --stat || true
git diff -- enhancements/hypershift/hypershift-ingress-default-certificate.md | sed -n '1,220p' || true
echo "== search for IngressDefaultCertificateReference and validations =="
rg -n "IngressDefaultCertificateReference|validation:Pattern|validation:Description|validation:Minimum|LocalObjectReference|kubernetes.io/tls Secret|ingress default certificate" --glob '*.go' --glob '*.md' . || true
echo "== search repository-wide for DNS subdomain patterns =="
rg -n "DNS-1123|DNS subdomain|^[a-z0-9].*-.*\.?[a-z0-9]*$|Pattern=.*\\." --glob '*.go' --glob '*.md' . || trueRepository: openshift/enhancements
Length of output: 291
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== target relevant lines =="
sed -n '220,290p' enhancements/hypershift/hypershift-ingress-default-certificate.md
echo "== related searches =="
rg -n "IngressDefaultCertificateReference|validation:Pattern|validation:Description|validation:Minimum|LocalObjectReference|ingress default certificate|kubernetes.io/tls Secret|Secret.*Reference|MinLength|MaxLength" --glob '*.go' --glob '*.md' . || true
echo "== validation pattern search =="
rg -n "validation:Pattern=|validation:Pattern:" --glob '*.go' --glob '*.md' . || trueRepository: openshift/enhancements
Length of output: 50380
🌐 Web query:
Kubernetes v1.32 Secret metadata name DNS subdomain validation pattern
💡 Result:
In Kubernetes v1.32, the name of a Secret object must be a valid DNS subdomain name, as defined in RFC 1123 [1][2]. To satisfy the DNS subdomain validation pattern, the Secret name must meet the following requirements: - It must contain no more than 253 characters [2][3]. - It must consist only of lowercase alphanumeric characters, '-' (hyphen), or '.' (dot) [2][3]. - It must start and end with an alphanumeric character [2][3]. In the Kubernetes codebase, this validation is enforced by the IsDNS1123Subdomain function within the apimachinery package, which uses a regular expression to ensure the string conforms to the DNS subdomain format [3][4]. While the DNS subdomain standard (RFC 1123) is the primary constraint for resource names like Secrets, it is distinct from the DNS label standard (RFC 1035/1123) used for other resources, which is more restrictive and limited to 63 characters [2]. Note that while the Secret object name follows the DNS subdomain pattern, the keys used within the Secret's data or stringData fields have different, less restrictive requirements: they must consist of alphanumeric characters, '-', '_', or '.' [1][5].
Citations:
- 1: https://kubernetes.io/docs/concepts/configuration/secret/
- 2: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/
- 3: https://github.com/kubernetes/kubernetes/blob/HEAD/staging/src/k8s.io/apimachinery/pkg/util/validation/validation.go
- 4: https://github.com/kubernetes/apimachinery/blob/v0.32.2/pkg/util/validation/validation.go
- 5: https://kubernetes.io/docs/reference/kubernetes-api/core/secret-v1/
🌐 Web query:
github kubernetes/apimachinery IsDNS1123Subdomain regex v0.32.2
💡 Result:
In the Kubernetes apimachinery library version v0.32.2, the IsDNS1123Subdomain function uses the dns1123SubdomainRegexp regular expression to validate strings [1]. The validation logic is defined as follows: 1. The regex pattern is constructed from the dns1123SubdomainFmt constant, which is defined as: dns1123LabelFmt + "(\." + dns1123LabelFmt + ")*" [1] 2. The compiled regular expression object is: var dns1123SubdomainRegexp = regexp.MustCompile("^" + dns1123SubdomainFmt + "$") [1] 3. The IsDNS1123Subdomain function checks the input string against this regex and ensures the length does not exceed the defined constant DNS1123SubdomainMaxLength (253 characters) [1]. The dns1123LabelFmt constant, which supports this regex, defines a lowercase RFC 1123 label that must start and end with an alphanumeric character and may contain hyphens [1]. This ensures the subdomain conforms to standard DNS RFC 1123 subdomain naming conventions [1].
Citations:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import re
# Approximate Kubernetes DNS subdomain validation from apimachinery:
# DNS1123SubdomainMaxLength = 253.
# Each label matches RFC1123 label: lowercase alphanumeric with hyphens, start/end alphanumeric, max 63.
dns1123_label = r'[a-z0-9]([-a-z0-9]{0,61}[a-z0-9])?'
dns1123_subdomain = re.compile(r'^(?:' + dns1123_label + r'\.)+' + dns1123_label + r'|' + r'^' + dns1123_label + r'$')
cases = {
"single label": "my-secret",
"underscore": "my_secret",
"uppercase": "My-Secret",
"trailing-dot": "my-secret.",
"double dots": "my..secret",
"leading hyphen": "-secret",
"trailing hyphen": "my-",
"253 chars single": "a" * 253,
"254 chars single": "a" * 254,
"max label subdomain": "a" + "-1234567890" * 6 + "b" + ".example",
}
for name, value in cases.items():
ok = len(value) <= 253 and bool(dns1123_subdomain.fullmatch(value))
print(f"{name}: {'valid' if ok else 'invalid'} {value!r}")
PYRepository: openshift/enhancements
Length of output: 1062
Validate the Secret name as a Kubernetes DNS subdomain.
MinLength and MaxLength alone allow invalid Secret names such as my_secret, My-Certificate, -secret, and my-secret.. Add the Kubernetes DNS-subdomain validation pattern and include invalid-name tests for this field.
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md` around
lines 251 - 259, Update IngressDefaultCertificateReference.Name with the
Kubernetes DNS-subdomain validation pattern in addition to its existing length
constraints, rejecting names such as my_secret, My-Certificate, -secret, and
my-secret. Add validation tests covering these invalid values.
…luster admins Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
|
||
| - Serialization round-trip tests verifying that an N-1 HyperShift version can | ||
| safely ignore the new `defaultCertificate` field. | ||
| - Validation tests for the `IngressDefaultCertificateReference` type (CEL |
There was a problem hiding this comment.
does HCP have a spot for these?
There was a problem hiding this comment.
Clarified — added a note explaining that HyperShift does not have an OLM-based operator lifecycle so the standard operator SDK scorecard metrics don't directly apply. Instead, operational aspects are monitored via the HostedCluster status conditions and the existing HyperShift operator metrics.
AI-generated. Review for accuracy.
- Replace "managed-service operator" with "managed service provider" throughout - Remove redundant Story 2 (Certificate Provisioning), renumber remaining stories - Add DNS name and service provider certificate language to summary - Clarify that standalone OCP allows IngressController defaultCertificate override but HyperShift's HCCO continuously reconciles it - Specify control-plane namespace secret name (default-ingress-cert) - Mark ManagedCA Observer as pre-existing behavior - Simplify actor description to "automated system responsible for managing HostedClusters" - Add IngressCertificateSynced condition name for status reporting - Clarify unit tests cover both HostedCluster and HostedControlPlane APIs - Remove opaque downstream Jira ticket references from graduation criteria Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…r initial creation Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| } | ||
|
|
||
| // IngressDefaultCertificateReference references a TLS Secret by name. | ||
| type IngressDefaultCertificateReference struct { |
There was a problem hiding this comment.
Why not use corev1.LocalObjectReference?
There was a problem hiding this comment.
Nevermind. I see openshift/hypershift#9132 (comment) now.
There was a problem hiding this comment.
Good question. The implementation uses a dedicated IngressDefaultCertificateReference type rather than corev1.LocalObjectReference because:
- Validation constraints: The custom type carries kubebuilder validation markers (
MinLength=1,MaxLength=253) thatLocalObjectReferencedoes not have — it has a bareName stringwith no validation. - Documentation clarity: The godoc on the custom type explicitly documents the Secret type requirement (
kubernetes.io/tls) and required keys (tls.crt,tls.key). - Future extensibility: A dedicated type allows adding fields later (e.g. namespace for cross-namespace references) without modifying a shared Kubernetes type.
Added a rationale paragraph in the API section explaining this. See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
| Mitigation: If the referenced Secret is deleted, the sync chain will not have | ||
| new data to propagate. The existing certificate in the guest cluster remains in | ||
| place until the Secret is recreated or the `defaultCertificate` field is | ||
| cleared. The HyperShift Operator reports the sync status via an |
There was a problem hiding this comment.
Should the proposal explicitly call out adding this condition as part of the change?
It's assumed here that it exists already; however on L454 to 456 its an open question if it should be included.
There was a problem hiding this comment.
You're right — this was inconsistent. The condition was referenced as if it already existed on L379, but then listed as an open question on L454-456.
Fixed: the IngressDefaultCertificateSynced condition is now explicitly called out as part of this proposal. Removed the open question about status reporting. The condition is set on HostedCluster status with reason and message fields. See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
|
|
||
| ### E2E Tests | ||
|
|
||
| The E2E test suite (implemented in PR openshift/hypershift#9132) covers: |
There was a problem hiding this comment.
Shouldn't the test suite also cover negative paths? Examples: invalid cert data, mismatched key/cert, partial Secret update, source Secret deletion while field is set, Secret delete+recreate vs. update, certificate chain ordering.
There was a problem hiding this comment.
Agreed — added a "Negative and Edge Case Tests" subsection covering all the scenarios you listed:
- Invalid certificate data (non-PEM content)
- Mismatched key/cert pair
- Partial Secret update (missing
tls.key) - Source Secret deletion while
defaultCertificateis set - Secret delete+recreate vs. in-place update
- Certificate chain ordering (leaf → intermediate → root)
See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
| 1. The managed service provider updates the TLS Secret referenced by | ||
| `defaultCertificate` with new `tls.crt` and `tls.key` data. | ||
|
|
||
| 2. The HyperShift operator detects the Secret change and re-syncs the updated |
There was a problem hiding this comment.
Does "detects the Secret change" here mean reactive reconciliation via ensureReferencedResourceAnnotation, or periodic?
There was a problem hiding this comment.
It's reactive via ensureReferencedResourceAnnotation. Confirmed from the implementation — the function hashes the referenced Secret's content and stores it as an annotation on the HostedCluster. When the Secret changes, the hash changes, which triggers re-reconciliation via the controller's watch.
Updated the document to clarify this mechanism explicitly. See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
|
|
||
| - Removal/revert test coverage (clearing `defaultCertificate` reverts to | ||
| wildcard certificate). | ||
| - Soak time in ARO/ROSA staging environments. |
There was a problem hiding this comment.
Should we specifically time bound this? Like after 1 month or 2 months?
There was a problem hiding this comment.
Good point — updated to: "At least 30 days of soak time in ARO/ROSA staging environments with active certificate rotation testing." See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
| The implementation follows the established HyperShift pattern for syncing | ||
| resources from the management cluster to the guest cluster: | ||
|
|
||
| 1. **Source validation**: The HyperShift Operator validates that the referenced |
There was a problem hiding this comment.
Should DefaultCertificate be ignored when ingress capability is disabled? Maybe that never happens in managed services context?
There was a problem hiding this comment.
You're right that this doesn't happen in the managed services context. Added a note: in ARO/ROSA deployments the ingress capability is always enabled, so this edge case does not arise. For completeness, if ingress capability were disabled, defaultCertificate would have no effect since no IngressController would be created to consume it.
See ba22936.
AI-generated. Review for accuracy.
AI-generated. Review for accuracy.
…sal, negative tests, reconciliation mechanism, soak time bound, and ingress capability edge case Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
enhancements/hypershift/hypershift-ingress-default-certificate.md (1)
203-205: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy liftDefine validation of the complete TLS Secret.
Lines [203-205] require only the Secret and both keys to exist. Lines [518-523] require detection of malformed PEM data and mismatched keys. Define and enforce one contract before the first synchronization hop. Validate the certificate and key pair, preserve the last known-good target on failure, and report the failure condition.
As per path instructions, protect private key material and use vetted cryptographic handling.
Also applies to: 518-523
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md` around lines 203 - 205, Define one complete TLS Secret validation contract for the HyperShift operator’s defaultCertificate flow before any synchronization: require the Secret, valid PEM-encoded certificate and private key, and a matching certificate/key pair. Specify that invalid input prevents updates, preserves the last known-good target Secret, and reports a failure condition without exposing private key material; apply the same contract to both referenced validation sections.Source: Path instructions
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md`:
- Around line 524-526: Update the partial Secret rotation requirement in the
“Partial Secret update” section to require atomic validation of a matching
tls.crt/tls.key pair, or retention of the last known-good target until
validation succeeds. Add coverage for sequential one-key updates and assert that
the guest cluster never receives a mixed certificate/key pair. Ensure private
key material remains protected and cryptographic handling uses vetted
mechanisms.
- Around line 362-368: Update the proposal’s disabled-ingress behavior so the
HyperShift Operator does not synchronize the referenced TLS Secret, including
tls.key, when ingress is disabled. Remove or revise the statement that Secret
data is still synced and remains unused; if retention is required, explicitly
justify it and ensure no unnecessary private-key copy is created.
---
Outside diff comments:
In `@enhancements/hypershift/hypershift-ingress-default-certificate.md`:
- Around line 203-205: Define one complete TLS Secret validation contract for
the HyperShift operator’s defaultCertificate flow before any synchronization:
require the Secret, valid PEM-encoded certificate and private key, and a
matching certificate/key pair. Specify that invalid input prevents updates,
preserves the last known-good target Secret, and reports a failure condition
without exposing private key material; apply the same contract to both
referenced validation sections.
🪄 Autofix
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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: cb12cfbb-d65e-4fdf-b6b8-db220f444981
📒 Files selected for processing (1)
enhancements/hypershift/hypershift-ingress-default-certificate.md
| **Note on ingress capability**: In managed services deployments (ARO/ROSA), | ||
| the ingress capability is always enabled, so the interaction between | ||
| `defaultCertificate` and a disabled ingress capability does not arise in the | ||
| target use case. For completeness, if the ingress capability were disabled, | ||
| the `defaultCertificate` field would have no effect since no | ||
| IngressController would be created to consume it. The HyperShift Operator | ||
| would still sync the Secret data, but it would remain unused. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not replicate private keys when ingress is disabled.
The proposal explicitly syncs the referenced Secret even when no IngressController consumes it. This creates an unnecessary control-plane copy of tls.key. Skip synchronization while ingress is disabled, or define justified retention and verify that no unused private-key copy is created.
As per path instructions, protect private key material and avoid unnecessary copies.
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md` around
lines 362 - 368, Update the proposal’s disabled-ingress behavior so the
HyperShift Operator does not synchronize the referenced TLS Secret, including
tls.key, when ingress is disabled. Remove or revise the statement that Secret
data is still synced and remains unused; if retention is required, explicitly
justify it and ensure no unnecessary private-key copy is created.
Source: Path instructions
| - **Partial Secret update**: Update only `tls.crt` or only `tls.key` in the | ||
| source Secret and verify the sync chain handles the partial update | ||
| correctly (either syncing the full Secret or reporting an error). |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Make partial rotation behavior deterministic.
“Either syncing the full Secret or reporting an error” is not a safe contract. If the provider updates tls.crt and tls.key separately, the controller can propagate a mismatched pair. Require one atomic update with a matching pair, or preserve the last known-good target until validation succeeds. Test sequential one-key updates and verify that the guest cluster never receives a mixed pair.
As per path instructions, protect private key material and use vetted cryptographic handling.
🤖 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 `@enhancements/hypershift/hypershift-ingress-default-certificate.md` around
lines 524 - 526, Update the partial Secret rotation requirement in the “Partial
Secret update” section to require atomic validation of a matching
tls.crt/tls.key pair, or retention of the last known-good target until
validation succeeds. Add coverage for sequential one-key updates and assert that
the guest cluster never receives a mixed certificate/key pair. Ensure private
key material remains protected and cryptographic handling uses vetted
mechanisms.
Source: Path instructions
|
@redhat-chai-bot: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
4 participants
This enhancement proposes adding
defaultCertificateas a first-class optional field onIngressOperatorSpecin the HostedCluster/HostedControlPlane API. This enables cluster administrators and managed-service operators (ARO, ROSA) to specify a custom TLS certificate for the default ingress controller through the management plane.Tracking
Summary
Today, the IngressController's
defaultCertificateis hardcoded by HCCO to point to the HyperShift-generated wildcard cert. There is no field in the HCP API to override this. This enhancement adds aDefaultCertificatefield following the same pattern asendpointPublishingStrategy(already exposed onIngressOperatorSpec), enabling custom ingress serving certificates to be managed from the management plane.Key Design Decisions
default-ingress-cert— only the data source changesAI-generated. Review for accuracy.
@deads2k requested in Slack thread
Summary by CodeRabbit