Skip to content

OCPBUGS-76971: Update NetworkPolicy egress to support HyperShift custom API ports#3770

Open
rashmigottipati wants to merge 4 commits intooperator-framework:masterfrom
rashmigottipati:update-networkpolicy-wildcard-egress
Open

OCPBUGS-76971: Update NetworkPolicy egress to support HyperShift custom API ports#3770
rashmigottipati wants to merge 4 commits intooperator-framework:masterfrom
rashmigottipati:update-networkpolicy-wildcard-egress

Conversation

@rashmigottipati
Copy link
Member

Description of the change:

This PR updates NetworkPolicy egress rules in OLM v0 to support HyperShift deployments that use custom Kubernetes API server ports.

Motivation for the change:

The current NetworkPolicy rules hardcode port 6443 for Kubernetes API server access, which breaks HyperShift deployments that customize the API server port. Based on the latest guidance across OCP, we should:

  1. Use wildcard egress {} for kube-apiserver to allow all IPs/ports
  2. Use explicit DNS egress rules with ports 53 and 5353 (TCP/UDP) for DNS resolution

This approach aligns with related projects (catalogd, operator-controller) and the companion fix in operator-marketplace (OCPBUGS-66980).

Architectural changes:

Testing remarks:

Reviewer Checklist

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Bug fixes are accompanied by regression test(s)
  • e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
  • tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
  • Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
  • Docs updated or added to /doc
  • Commit messages sensible and descriptive
  • Tests marked as [FLAKE] are truly flaky and have an issue
  • Code is properly formatted

Closes https://issues.redhat.com/browse/OCPBUGS-76971

Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
@openshift-ci
Copy link

openshift-ci bot commented Feb 16, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign dtfranz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
@rashmigottipati
Copy link
Member Author

cc @kuiwang02 can you please verify this PR?

@bandrade
Copy link
Contributor

/label qe-approved
/verified by @bandrade

@openshift-ci openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Feb 19, 2026
Comment on lines +52 to +54
// Wildcard allow all IPs/Ports for kube-apiserver
{},
// Wildcard allow all IPs with DNS ports
Copy link
Contributor

Choose a reason for hiding this comment

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

The {} seems to make the specific ports for DNS redundant.
It's either allow all through, or allow these specific DNS ports.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup this is intentional and adheres with the guidance from the networking team. The reasoning being that if we ever tighten the kube-apiserver rules in the future, we will have DNS rules already separated out and won't accidentally break DNS resolution.

But you're right that the DNS rules currently have no enforcement effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

qe-approved Signifies that QE has signed off on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Comments