Support custom Vault secret prefix

[sam-heilbron]

Description

Allow injecting a custom pathPrefix for Vault secrets, historically this was hard-coded to "secret".

Context

Why is this configuration valuable?

It allows for users to use custom secrets engines and for multitenancy-ness for organizations with different/separated secrets paths.

How did this work before?

This value was previously hardcoded in solo-kit https://github.com/solo-io/solo-kit/blob/1d799ae290c2f516f01fc4ad20272d7d2d5db1e7/pkg/api/v1/clients/vault/resource_client.go#L309

How did we verify this?

• Created a test to verify that our vault client can interact with the custom --vault-path-prefix fed in by user. The test can create a secret using the custom path prefix, and can also read from Vault.
• We updated our test setup to allow for the creation of a custom -path for the Vault test server to test the pathPrefix. This matches how Vault customers enable new secrets engines with custom path.

Checklist:

• I included a concise, user-facing changelog (for details, see https://github.com/solo-io/go-utils/tree/master/changelogutils) which references the issue that is resolved.
• If I updated APIs (our protos) or helm values, I ran make -B install-go-tools generated-code to ensure there will be no code diff
• I followed guidelines laid out in the Gloo Edge contribution guide
• I opened a draft PR or added the work in progress label if my PR is not ready for review
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

BOT NOTES:
resolves #6184

[github-actions]

Visit the preview URL for this PR (updated for commit c5ec0ea):

https://gloo-edge--pr6283-expose-vault-secret-q9p2e8to.web.app

_{(expires Thu, 21 Apr 2022 15:16:49 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[solo-changelog-bot]

Issues linked to changelog:
#6184

[inFocus7]

re-running build, flake #2838

[sam-heilbron]

The most recent build-bot failure: [Fail] Happy path Rest Eds Enabled: (V3) in memory ssl sni [It] should work with ssl is one we have not seen before. My instinct is to say this is due to test pollution.

In the logs I noticed a message that seems to occur whenever we see this type of new flake:

Step #10 - "test": WARN	gloo.setup.gloosnapshot.event_loop.envoyTranslatorSyncer	Proxy had invalid config after xds sanitization	{"proxy": "name:\"gateway-proxy\" namespace:\"gloo-system\"", "error": "2 errors occurred:\n\t* invalid resource gloo-system.gateway-proxy\n\t* WARN: \n  [Route Warning: InvalidDestinationWarning. Reason: *v1.Upstream { default.local-test-upstream-70-ssl } not found]\n\n"}
Step #10 - "test": INFO	gloo	respond open watch 1[] with new version "14695981039346656037"

I believe that #6301 will resolve this issue. I vote that for now we kick this flake and track it. And if I can confirm that this linked PR will resolve the issue then I can close any new flake issues

[sam-heilbron]

/kick

[sam-heilbron]

/kick New failed test, same core issue as mentioned above https://storage.googleapis.com/solo-public-build-logs/logs.html?buildid=dc8ff3f1-81c8-4704-9a2a-119c3250e4b6

[inFocus7]

had flake #6253

[inFocus7]

/kick

[inFocus7]

/kick no fail reason shown, CI build failed during "docker-push-extended": Pushed

[inFocus7]

/kick

  Expected
      <core.Status_State>: 1
  to equal
      <core.Status_State>: 2

kicking due to possible flake in test

[nfuden]

/kick Locally the kv test that just failed doesnt. So its a flake... though we should consider how we can fix it if this turns out to be truly a flake Edit: too many times to be a real flake minimally a weird test setup

[inFocus7]

test flake in CI / k8s regression tests (glooctl, false) (pull_request). Istio/istioctl failed to install, created new issue for it #6316

[Rachael-Graham]

doc

[nfuden]

Looks good. Most of the decisions were in the solokit PR.