-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
openshift-4.19
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
- Proposed title of this feature request:
OpenShift 4: Methods for restricting access to OpenShift API at node layer (CIDR whitelisting)
2. What is the nature and description of the request?
Customer requirement for blocking access to OpenShift APIserver (api.<cluster>.<domain>:6443) when an external LB is not utilized or accessible, or when IPI cluster is deployed and network access controls are not available
3. Why does the customer need this? (List the business requirements here)
Security requirement on Hub/Spoke RHACM cluster - deploying cluster into a disconnected environment is less feasible given the nature of the project. Need to ensure that the apiserver cannot be probed/queried by anyone other than authorized cidr group as a security requirement,
4. List any affected packages or components.
OpenShift-Node nftable rules
KubeApiserver
//Additional contexts/goals:
Questions/Concerns: 1. IngressNodeFirewall Alternatives: Given the webhook restriction [blocking api port restriction by policy is denied], is there a way to structure the IngressNodeFirewall rules or use another OpenShift-native mechanism to achieve the desired API access restriction (whitelisting specific CIDRs and denying others) without conflicting with critical services? For example, could we adjust the rule order, use a different operator, or leverage another Kubernetes resource? 2. HyperShift-Specific Considerations: Since this is a HyperShift control plane cluster, you mentioned that the API is exposed via a LoadBalancer or NodePort service in the management/hub cluster. Can the IngressNodeFirewall Operator be applied at the management cluster level to restrict API access? If so, how should we configure it to target the API service correctly? 3. Route Annotations: You mentioned using IP whitelist annotations for the console route. Could a similar approach be applied to the API service route (if it exists) to restrict access based on client IPs? If so, could you provide guidance or an example configuration? 4. Fallback Options: If OpenShift-native solutions are not viable, are there any supported configurations (e.g., NetworkPolicy or other mechanisms) that could help us achieve this restriction within the cluster without relying on external devices?
