Closed kian99 closed 1 month ago
After investigating further, I see the charm lib allows us to pass the egress_subnet in the data bag which is what we were doing but doesn't work well for a K8s -> machine setup. I can change our charm to accept an egress subnet via config and that would resolve this.
Hello @kian99 thank you for opening this issue. We should be looking at it in the next couple of days. Thank you.
The issue was with the egress_subnet being passed by the requirer in the relation.
The lib now allows passing more than one address as a list, which should allow the requirer to cover every use case.
For the requirer to pass the address that is specified using --via
the requirer charm should pass the list in self.model.get_binding(relation).network.egress_subnets][0].subnet
instead of self.model.get_binding(relation).network.interfaces[0].subnet
.
Bug Description
When relating an app on a different model to Vault, especially when relating from an running in a K8's cluster, the egress IP address of requests may not match the IP address of the source. In k8s for example, the k8s pod where the request originated will have a different IP than the egress IP (usually that of the node). In this case I tried to use
juju relate --via
to express to Vault what IP range to whitelist in the relation. But the charm doesn't seem to understand/use this value.To Reproduce
Similar to #243,
--via 10.0.0.0/8
Environment
This was consistently replicated locally as described above.
Relevant log output