© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
First interface PR for after 21.01 release [0] will stop the bleeding on this bug but not resolve the need for an "external" binding concept [1] [2].
Ultimately, the solution will need to be implemented in the vault charm itself with an address selection function (potentially get_vault_url) that can take in quite a few considerations.
We have a few primary problems for the original intention of external binding that need consensus on solutions
* Juju does not have the primitives to determine if a request is coming from an internal or external source
* Juju does not have a per relation *ID* binding, i.e. "secrets:2" rather than "secrets"
* It is not that we have too few possible bindings but too many: "access", "external", "certificates", "secrets", "cluster"
* It is very likely if not inevitable that the relation, secrets, could be bound to a different space than the extra binding, access. How do we choose?
Possible solutions
* It is possible the "external" binding concept needs to be abandoned.
* The vault-kv interface can add an "external" variable to the request such that the vault charm's get_vault_url can then be guaranteed to use its "external" binding.
[0] https:/
[1] https:/
[2] https:/