Enable use of an address outside the cluster if desired

[mhjacks]

• Support a Vault entirely outside the patterns cluster

[mbaldessari]

Has this been tested in an actual external vault setup?

[mhjacks]

Candidly, no. :) I don't have a fully external setup. Akos pointed out on the team call this morning that the auth model might be a little too restrictive for this model (since we literally don't know anything about the external one), so I have pushed new commits that (hopefully) address that. In the new model, an auth block will be passed to the clustersecretstore object in its entirety

[darkdoc]

I managed to test this, I have successfully used this chart on my cluster, pointing to a vault running on an other cluster (external) I used this branch of mcg.
The only question from me, is how should the secret loading be in these external vault cases?
In case of keeping the default secretStore vault backend, the pattern installation would fail, since there are no vault pods in the cluster.
Even if we switch to some other backend, the question still remains, how/what should the secret loading do in this case?
I suggest that we document that in this external vault special case we do not load secrets to vault (that would not be possible) and possible anywhere else either. (there is no point in loading the secrets to the kubernetes/none backend, if there IS an external vault used)
Some changes might be needed to support this on a per pattern basis or even in the cluster utils collection.
Otherwise the chart changes looks good to me.

[mhjacks]

@darkdoc Added note about disabling the secrets loader, and a disclaimer about managing/injecting secrets when we don't manage the vault

[darkdoc]

/lgtm