Define order of vault init container

[drpebcak]

I have an application which uses an init container to do database migrations. This init container wants to have secrets from vault in it.

The vault init container is injected, but it never starts because the db migration sidecar starts first.

Is it possible to get the vault init container to run first?

[jasonodonnell]

Hi @drpebcak, it's currently not possible to set the order for the init container (it's always going to come last since we append it). It's should be possible to support this, though.

[drpebcak]

This is a blocker for us, so hopefully it’s something that could be implemented fairly soon.

Thanks for your response!

[jasonodonnell]

Something like this should be possible(where the default is append), exact placement would not be:

vault.hashicorp.com/agent-inject-init-order: "prepend"
vault.hashicorp.com/agent-inject-init-order: "append"

[drpebcak]

Sounds good to me. I saw there was a related issue that this might solve with istio. I think this approach would work for 99% of use cases.

[jjensen90]

I also ran into the init container order being an issue and came here to find if there was an existing issue, I had to implement a clunky workaround. I would also really appreciate this feature (just prepend/append would be perfect).

[rvdh]

I also ran into the init container order being an issue and came here to find if there was an existing issue, I had to implement a clunky workaround. I would also really appreciate this feature (just prepend/append would be perfect).

@jjensen90 could you describe the workaround you implemented?

I'm having this issue with Istio. The Istio init container runs first, which sets firewall rules to redirect all traffic to the Envoy sidecar. The Vault init container runs second, but can't reach Vault, because the traffic is redirected to the Envoy sidecar, which obviously isn't running yet.. so Connection refused.

[zystem]

I think there is no need for "prepend" and "append" annotations. I think "vault-agent-init" must be always first. I have no ideas about how it can create problems or can break something.
And there are no technical problems to implement it. Just create temporary array, fill the first element of it with "vault-agent-init" and append it with existing init containers. Then rewrite an array of init containers in kubernetes with this temporary array.
Additionally, I found what /vault/secrets not mounted in init containers others than "vault-agent-init" . Need to fix it too.

[jasonodonnell]

Hi @zystem, thanks for the note about volume mounts not being present in other init containers. I have fixed that in #91 .

I think being able to configure if Vault Agent runs first or last is still desirable. For example, istio may want to run first to configure iptables prior to Vault Agent running. There could be other examples not thought of so having a configurable makes this more flexible.

[drpebcak]

Yeah I would say in general it doesn't hurt to keep the old behavior for compatibility!