✨ Add support for symmetric allowed address pairs

[trihoangvo]

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.

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

[openshift-ci]

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

• DOWNSTREAM_OWNERS

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

[openshift-ci]

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.

[stephenfin]

Hi @trihoangvo. I suspect you have the wrong repo. This is an OpenShift fork of https://github.com/kubernetes-sigs/cluster-api-provider-openstack that only exists for things like CVE tracking. You likely want to open your PR against the upstream repo at https://github.com/kubernetes-sigs/cluster-api-provider-openstack instead.

[trihoangvo]

@stephenfin OpenShift uses upstream CAPO (https://github.com/kubernetes-sigs/cluster-api-provider-openstack) but has stayed at the branch release-0.9 since many years. Starting from v0.10, there are refactoring in CAPO and OpenShift's MAPO is not compatible anymore.

If we create a PR to main of upstream CAPO, we cannot backport it to release-0.9 (due to the refactoring, many differences). Should we create a PR to the branch release-0.9?

[stephenfin]

@stephenfin OpenShift uses upstream CAPO (kubernetes-sigs/cluster-api-provider-openstack) but has stayed at the branch release-0.9 since many years. Starting from v0.10, there are refactoring in CAPO and OpenShift's MAPO is not compatible anymore.

Oh, so you're attempting to add something to MAPO? Would it be possible to file an RFE or bug in Red Hat Jira and link it here so we can assess on that basis?

If we create a PR to main of upstream CAPO, we cannot backport it to release-0.9 (due to the refactoring, many differences). Should we create a PR to the branch release-0.9?

What you've done here is likely correct if we opt to do this in MAPO (which is a discussion we still need to have: see above request to file a Jira ticket). However, all MAPI providers will eventually be replaced by CAPI providers (see e.g. https://github.com/openshift/cluster-capi-operator) so this feature will need to exist upstream in any case to prevent regressions when the migration happens. Does this feature already exist upstream? If not, it probably makes sense to get it merged there first since we will have to carry the feature forward otherwise, which is not something we typically do. This can happen in parallel with the discussion on Jira.