feat: add support for Hashicorp Vault mTLS

[rodrigorfk]

Problem Statement

Vault server can be configured to strictly enforce clients to present client certificates while connecting to the server in the HTTPs transport layer.

It is possible to configure Vault to use a client certificate to secure the transport layer (tcp listener documentation):

listener "tcp" {
  tls_disable = false
  tls_cert_file = "/vault/tls/server.crt"
  tls_key_file = "/vault/tls/server.key"
  tls_client_ca_file = "/vault/tls/ca.crt"
  tls_require_and_verify_client_cert = true
}

When Vault is configured in the way above, there is no possibility to properly configure the Vault provider in the SecretStore by using existing CRDs.

Related Issue

Fixes #1139

Proposed Changes

This change is adding a new section in the Vault provider allow passing the client TLS certificate to the transport layer as following:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
  namespace: example
spec:
  provider:
    vault:
      server: "https://vault.acme.org"
      path: "secret"
      version: "v2"

      # client TLS related configuration
      caBundle: "..."
      tls:
        clientCert:
          name: "my-cert-secret"
          key: "tls.crt"
        secretRef:
          name: "my-cert-secret"
          key: "tls.key"

      # the authentication methods are not really related to the client TLS configuration
      auth:
        ...

Checklist

• I have read the contribution guidelines
• All commits are signed with git commit --signoff
• My changes have reasonable test coverage
• All tests pass with make test
• I ensured my PR is ready for review with make reviewable

[moolen]

Very nice work, thank you a lot for your contribution 🙇
I'm super happy to see e2e tests, too 🥳 🏅

[moolen]

These are a lot of tests that need to run, although they don't provide a lot of value. In essence only one test is needed to verify that the mTLS is being accepted by vault.

As mentioned above: if we add one additional listener for vault - one that requires mTLS - then we can add another store which has mTLS enabled and we just need to add one test to the suites/provider/cases/vault/vault.go file, something like this:

// ..
framework.Compose(
  withTokenAuthAndMTLS, f, common.FindByName, useMTLSAndTokenAuth)
// ...

[rodrigorfk]

Good point, thanks for the suggestion, I will update the PR to follow it.

[rodrigorfk]

@moolen , as commented above, using a second listener is not that simple, the Vault helm chart does not allow customising the Service and add the new port to it, I kept the vault_mtls.go implementation and reduced the number of tests to cover just a single SecretStore and ClusterSecretStore test case. What do you think?

[moolen]

/ok-to-test sha=0a83f73

[moolen]

/ok-to-test sha=a2ebf4b

[sonarcloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

1 New issue
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[rodrigorfk]

@moolen I have performed a final amend to the PR because I notice a flaky integration test due to concurrency caused by the ClusterSecretStore left orphan after each Vault e2e test is executed, it should be fixed now, but I also believe is worth performing a few rounds of the vault ginkgo label suite just to make sure there is no race condition left.

I also tried to reduce the code complexity of the newConfig function as reported by Sonar above by extracting my code into a new func, however Sonar still complaining about the complexity of the existing code.

[moolen]

/ok-to-test sha=082bd9c

[moolen]

Thank you @rodrigorfk, i'll take a look. Don't mind the sonarcube failures, no need to fix it right now :)

[moolen]

LGTM, thank you for your contribution! 🏅

// edit: i ran the e2e tests a couple of times, looks good!