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 is built with operator-sdk and maintains a tight dependency on the AWS cluster provider, specifically pinned to the OpenShift fork of cluster-api-provider-aws to access v1beta1 API features. According to GitGenius activity tracking, the repository shows a median issue and pull request response latency of 21.2 hours across tracked items, with sebrandon1 identified as the most active triager and contributor. The repository maintains overlapping contributors with openshift/certman-operator, openshift/hive, and openshift/image-registry, indicating integration points within the broader OpenShift ecosystem.
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.
