vault agent: allow injecting a CA-cert via configMap (instead of a secret)

[rdxmb]

Is your feature request related to a problem? Please describe.

I wanted to use the vault agent to connect to my vault instance running in the same kubernetes cluster. Everything worked fine except the use of an own CA, which is kind of frustrating.

With the trust-manager https://cert-manager.io/docs/trust/trust-manager/ , there is such a great solution to have the own CA as a configMap in all my namespaces.

However, the vault agent annotation for getting the CA-certificate mounted in the sidecar container must point to a kubernetes secret instead.

Describe the solution you'd like

I'd like to have an annotation like vault.hashicorp.com/ca-cert-configmap: "cluster-ca-certificate" to mount the configMap which exists already by trust-manager in every namespace.

Describe alternatives you've considered
Using AGENT_INJECT_VAULT_CACERT_BYTES , which is not useful when having different vault-instances with different CA-certificates.

Additional context
We use our own CA to have tls for all of our k8s-internal traffic. Vault also uses this. Here is my helm values:

# https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-raft-deployment-guide#configure-vault-helm-chart
global:
  enabled: false
  tlsDisable: false
server:
  enabled: true
  # Run Vault in "HA" mode. There are no storage requirements unless the audit log
  # persistence is required.  In HA mode Vault will configure itself to use Consul
  # for its storage backend.  The default configuration provided will work the Consul
  # Helm project by default.  It is possible to manually configure Vault to use a
  # different HA backend.
  ha:
    enabled: true
    replicas: 5
    # Enables Vault's integrated Raft storage.  Unlike the typical HA modes where
    # Vault's persistence is external (such as Consul), enabling Raft mode will create
    # persistent volumes for Vault to store data according to the configuration under server.dataStorage.
    # The Vault cluster will coordinate leader elections and failovers internally.
    raft:
      # Enables Raft integrated storage
      enabled: true
      config: |
        ui = true

        storage "raft" {
          path = "/vault/data"
        }
       
        listener "tcp" {
          tls_disable = "false"
          address     = "0.0.0.0:8200"
          cluster_address = "[::]:8201"
          # Enable unauthenticated metrics access (necessary for Prometheus Operator)
          #telemetry {
          #  unauthenticated_metrics_access = "true"
          #}          
          tls_cert_file = "/tls/vault-server/tls.crt"
          tls_key_file = "/tls/vault-server/tls.key"
          tls_min_version = "tls12"
        }

  # This configures the Vault Statefulset to create a PVC for data
  # storage when using the file or raft backend storage engines.
  # See https://developer.hashicorp.com/vault/docs/configuration/storage to know more
  dataStorage:
    # Size of the PVC created
    size: 1Gi

  # This configures the Vault Statefulset to create a PVC for audit
  # logs.  Once Vault is deployed, initialized, and unsealed, Vault must
  # be configured to use this for audit logs.  This will be mounted to
  # /vault/audit
  # See https://developer.hashicorp.com/vault/docs/audit to know more
  auditStorage:
    enabled: true
    # Size of the PVC created
    size: 1Gi
    
  volumes:
  - name: ca-certificates
    configMap:
      name: cluster-ca-certificate-production
      defaultMode: 0644
      optional: false
      items:
      - key: ca-certificates.crt
        path: ca-certificates.crt
  - name: tls-cert
    secret:
      secretName: vault-server-certificate
  volumeMounts:
  - mountPath: /etc/ssl/certs/
    name: ca-certificates
    readOnly: true  
  - mountPath: /tls/vault-server
    name: tls-cert
    readOnly: true
ui:
  enabled: true
  pusblishNotReadyAddresses: false
  activeVaultPodOnly: true
injector:
  enabled: false
csi:
  enabled: false
serverTelemetry:
  enabled: false