Skip to content

✨ Add support for symmetric allowed address pairs#400

Draft
trihoangvo wants to merge 1 commit intoopenshift:release-0.9from
opentelekomcloud-blueprints:symmetric_allowed_address_pair
Draft

✨ Add support for symmetric allowed address pairs#400
trihoangvo wants to merge 1 commit intoopenshift:release-0.9from
opentelekomcloud-blueprints:symmetric_allowed_address_pair

Conversation

@trihoangvo
Copy link

What this PR does / why we need it:

  • In the current implementation of vanilla OpenStack, when a network port of the server is created, we can set the allowed_address_pairs to the IP address of the VIP port so that the underlying network (OVS/Bridge) unconditionally trusts all traffic originating from the VM port with the VIP as the source address.
  • The consequence:
    • If an orphan or zombie VM has the VIP, still get the public traffic or
    • If the VM is compromised, a hacker can use the VM as a springboard to launch attack against internal or public network by spoofing the VIP.
  • Some OpenStack deployments require symmetric allowed address pairs on VIP ports due to stricter Neutron port security configurations (stricter reverse path validation) to prevent the above scenarios.
  • This PR adds the following config symmetricAllowedAddressPairs, if set to true, when the VM port is newly created with the allowed address pairs of the VIP, we also update the allowed_address_pairs of the corresponding VIP port with the IP address of the VM port for bi-directional security.
Screenshot 2026-03-05 112054

Special notes for your reviewer:

Set to draft for internal discussion with Red Hat on the 18th of March.

TODOs:

  • squashed commits
  • if necessary:
    • includes documentation
    • adds unit tests

/hold

* In the current implementation, when a network port of the server is created,
  we can set the 'allowed_address_pairs' to the IP address of the VIP port so that
  the VM allows the traffic destinated for the VIP port to go through.
* Some OpenStack deployments require symmetric allowed address pairs on VIP ports
  due to stricter Neutron port security configurations (stricter reverse path
  validation).
* In such a case, this commit adds the following config "symmetricAllowedAddressPairs",
  If set to true, also updates the allowed_address_pairs of the VIP port with the IP
  address of the VM port for bidirectional security.
@openshift-ci openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. labels Mar 5, 2026
@openshift-ci
Copy link

openshift-ci bot commented Mar 5, 2026

[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.

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

@openshift-ci openshift-ci bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Mar 5, 2026
@openshift-ci
Copy link

openshift-ci bot commented Mar 5, 2026

Hi @trihoangvo. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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 kubernetes-sigs/prow repository.

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

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant