Make injector.external(Bao|Vault)Addr take precendence over global.external(Bao|Vault)Addr#158
Make injector.external(Bao|Vault)Addr take precendence over global.external(Bao|Vault)Addr#158baurmatt wants to merge 3 commits intoopenbao:mainfrom
Conversation
…ternal(Bao|Vault)Addr Previously it used to be the other way around. This had multiple disadvantages: 1. More specific configuration should override broader values. 2. Setting the injector specific config (injector.external(Bao|Vault)Addr) led to server being disabled. 3. Injector cannot be configured to connected to a external (e.g. Proxy) URL while still having OpenBao run in-cluster. Fixes openbao#157. Signed-off-by: Matthias Baur <m.baur@syseleven.de>
baurmatt
changed the title
test/unit/injector-deployment.bats
Outdated
| } | ||
|
|
||
| @test "injector/deployment: global.externalBaoAddr takes precendence over injector.externalVaultAddr" { | ||
| @test "injector/deployment: injector.externalVaultAddr takes precendence over global.externalBaoAddr" { |
There was a problem hiding this comment.
hi @baurmatt
Thanks for your PR.
Please change the check to check precedence of injector.externalBaoAddr over global.externalBaoAddr and add second test checking precedence of injector.externalBaoAddr over injector.externalVaultAddr
| */}} | ||
|
|
||
| {{- define "openbao.externalAddr" -}} | ||
| {{- define "openbao.global.externalAddr" -}} |
There was a problem hiding this comment.
I'm asking myself if we should even change this to openbao.global. or jst keep the openbao.externalAddr and have the addiional openbao.injector.externalAddr just take precedence.
There was a problem hiding this comment.
@baurmatt is there a specific reason for the global prefix?
There was a problem hiding this comment.
I've added the global prefix to make it clearer why variable to function works with. I personally would mix up global and injector addr in this function. It's currently a clean way to work around the "legacy" vault variables.
…bal.externalBaoAddr
…jector.externalVaultAddr
2 participants
Description
Previously it used to be the other way around. This had multiple disadvantages:
Rationale
Fixes #157.
Checklist
CONTRIBUTING.mdguideChart.yamlif feasible according to Semantic versioningartifacthub.io/changesannotation inChart.yamlCHANGELOG.mdREADME.mdfiles using helm-docsDCO ownership statement
and this change did not use post-BUSL-licensed code from HashiCorp.
Existing MPL-licensed code is still allowed, subject to attribution.
Code authored by yourself and submitted to HashiCorp for inclusion is
also allowed.