The cloud-ingress-operator is a Kubernetes operator built in Go that manages the public and private accessibility modes of OpenShift Dedicated 4.x clusters. It enables toggling between public and private configurations for critical cluster endpoints through custom Kubernetes resources, specifically the APIScheme and PublishingStrategy custom resources. The operator addresses a specific operational need within OpenShift Dedicated environments where cluster administrators and SRE teams must maintain access to clusters while allowing customers to control external accessibility.
The operator manages two primary cluster components independently: the default API server endpoint at api.<cluster-domain> and the ingress endpoints, with support for a default ingress at *.apps.<cluster-domain> and an optional secondary ingress at *.apps2.<cluster-domain>. To ensure continued access for Hive and SRE personnel, the operator creates an additional admin API endpoint, typically named rh-api.<cluster-domain>, which remains accessible regardless of the public or private configuration chosen by the customer. This separation of concerns allows customers to restrict external access while preserving operational capabilities for cluster management.
The APIScheme custom resource instructs the operator to create and configure the admin API endpoint, including security group rules that control which traffic sources can access the endpoint. The PublishingStrategy custom resource handles the toggling of privacy modes, allowing independent configuration of the API server and ingress endpoints. Users can specify whether each endpoint should be publicly accessible or private, configure TLS certificates for ingresses, and define route selectors. The operator supports configuring additional application ingresses beyond the default, though OpenShift Dedicated currently limits deployments to the default plus one additional ingress.
The operator includes deprecation handling for the applicationIngress feature, with version-aware behavior that changes based on the OpenShift Container Platform version. For clusters running OCP 4.13.0 or greater with the legacy-ingress-support feature label disabled, the operator does not reconcile IngressController resources at all. For earlier versions, it continues to manage the default ingress controller but prevents creation of additional apps2 ingress controllers, with exceptions for customers with existing apps2 installations who can continue managing them until migration to natively managed second ingress controllers.
Testing and debugging capabilities are documented for both manual deployment scenarios and local development. The operator can be manually deployed to clusters by pausing syncsets, building custom images, and applying deployment manifests. Manual testing procedures address race conditions with the cluster-ingress-operator by providing step-by-step validation of ingress controller creation and configuration. Developers can debug the operator on existing OSD clusters by scaling down competing operators and using standard debugging tools like VSCode with appropriate launch configurations.