Octavia Loadbalancer security group is using the wrong source ip rule

This is potentially a duplication of: https://bugs.launchpad.net/charm-openstack-integrator/+bug/1884995

Same problem here, tried what suggested on comment https://bugs.launchpad.net/charm-openstack-integrator/+bug/1884995/comments/8 but no luck.

Facing it as well, Bionic / Ussuri, K8s on OpenStack with openstack-integrator charm. Workaround to allow 6443 from vrrp_ip to the backend helped.

As a follow-up to my previous commment: the underlay cloud is Bionic / Ussuri with Neutron OVS.

I couldn't reproduce it in the first place, but I think I know what's happening here.

tl;dr `juju expose kubernetes-master` may be the easiest workaround but it will expose the port 8443 to everywhere.

It would be nice to tweak the LB members' rule to make it work out of the box though.

(there is a discussion about the expose feature but it's separate anyway: https://discourse.charmhub.io/t/granular-control-of-application-expose-parameters-in-the-upcoming-2-9-juju-release/3597)

The k8s-master unit/machine is covered by 3 security groups. Juju model, unit/machine, and lb members' one.

$ openstack server show juju-f8a3c5-k8s-on-openstack-0 -c security_groups
+-----------------+-----------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+-----------------------------------------------------------------------------------------+
| security_groups | name='openstack-integrator-f4720ef8a3c5-kubernetes-master-members' |
| | name='juju-6fda9e38-0c87-4a13-88f7-563386e719a9-fad73522-1466-41c0-8570-f4720ef8a3c5-0' |
| | name='juju-6fda9e38-0c87-4a13-88f7-563386e719a9-fad73522-1466-41c0-8570-f4720ef8a3c5' |
+-----------------+-----------------------------------------------------------------------------------------+

The model one is to allow all traffic inside the same model which is not applicable to Amphora instance <-> k8s-master since Amphora is outside of Juju model's security group.

Then, lb members' rule allows traffic to 6443 only from /32 which is LB's vip_address.

$ openstack security group rule list openstack-integrator-f4720ef8a3c5-kubernetes-master-members
+--------------------------------------+-------------+-----------+---------------+------------+-----------+-----------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+---------------+------------+-----------+-----------------------+----------------------+
| 1b5a9b4a-c9f5-4730-a6ee-b53ed672d3aa | None | IPv6 | ::/0 | | egress | None | None |
| 7e7cf826-6732-4f26-89b0-0c27f4b2788e | None | IPv4 | 0.0.0.0/0 | | egress | None | None |
| ea4e048d-a164-431c-b44f-96076a41c859 | tcp | IPv4 | 10.5.5.116/32 | 6443:6443 | ingress | None | None |
+--------------------------------------+-------------+-----------+---------------+------------+-----------+-----------------------+----------------------+

But the unit/machine one can allow access to 6443 from anywhere when the application is expose=true in Juju model. And it's enabled by default in charmstore bundles: https://github.com/charmed-kubernetes/bundle/blob/045be1ee3cf544f67298fd22050cfbca98337bd4/fragments/k8s/core/bundle.yaml#L6-L13

$ openstack s...

As a note, this is not a duplicate of https://bugs.launchpad.net/charm-openstack-integrator/+bug/1884995 because the latter is about LBs created by the cloud-provider-openstack component of K8s, whereas this is about LBs created by the openstack-integrator charm itself.

Still facing this issue on jammy/yoga deployment using stable channel, revision 53.
CK8s bundle is generated via fce bundle builder feature.
Used the workaround Nobuto mentioned i.e. juju expose kubernetes-control-plane. One thing to note also is that the latest charmstore charmed-kubernetes bundle no longer exposes kubernetes-control-plane.

Will file a bug against fce to make bundle builder generate a bundle with `expose: true` for kubernetes-control-plane but this still feels like a bug on openstack-integrator.

So are there any plans to fix this? Or do you accept pull-requests fixing this?

Edit: I provided a fix for this. Funny enough: the base was already there but not used.

https://github.com/charmed-kubernetes/charm-openstack-integrator/pull/8

Hey! This is still on our radar and thanks for the PR!