Use configmap for the VaultConnection

[sebglon]

Is your feature request related to a problem? Please describe. Give the choice to use configmap to share vault caCert. The idea is to use trust-manager to inject the caCert on the desired namespace. (like the kubeRootCa.crt provided by kubernetes)

Describe the solution you'd like Add a field caCertConfigMapRef

Describe alternatives you've considered Another solution is to have a webhook managed by the operator to inject the caCert directly on the vaultConnection.

[TheLonelyGhost]

I'm not sure I understand the reasoning for this. I understand it relates to using trust-manager, but I'm not sure I understand why they're doing this either.

Kubernetes has a type called kubernetes.io/tls so it can hold this datatype specifically. It has a very uniform scheme for naming attributes and what to expect in each of those attributes. Semantically, it seems better to stick with what's provided in the core platform, right? Am I missing something?

[sebglon]

Using a configmap to propagate CACert is more easy than a secret. The goal is to automate this propagation accross many Namespaces. And we don't want to give access to an automation tooling to upgrade secrets on all our namespaces. for security reason, we prefer to guive access to configmaps than secrets.

that's the same reason why cert-manage create the new trus-manager app to propagate cacert accross namespaces.

The goal here for us is not to provide de Kubernetes Cacert but the Vault cacert for the vaultConnection on many namespaces. Because our vault use dedicated cacert that is not the kubernetes cacert (for security reason)

[TheLonelyGhost]

Ah, that makes a lot more sense now. The RBAC system built into kubernetes doesn't allow for granularity of just one secret with a certain label/annotation/type, for instance, and instead would allow access to all secrets across all namespaces. At least with Vault, it's the very nature of the operator to manage all secrets. 👍

[mrtaormina]

+1

OpenShift provides a way to inject the cluster's trusted CA bundle into a config map without needing to manually manage a standalone CA bundle. This is only allowed for config maps, not secrets. Allowing caCertConfigMapRef, in addition to the already existing caCertSecretRef, in the VaultConnection CRD would simplify setup and management on OpenShift.

The bundle gets injected to a key named ca-bundle.crt, you would also need to allow optional customization of a key. For example:

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
  namespace: vso-example
  name: example
spec:
  caCertConfigMapRef:
    name: my-trusted-bundle
    key: ca-bundle.crt

[nia-potato]

@kschoche do we have any updates on this one by any chance?

[sandeeprudraraju]

Any updates on this request. please