Keyfactor / ejbca-cert-manager-issuer

External issuer for cert-manager for EJBCA
Apache License 2.0
3 stars 3 forks source link

Why store CA-bundle as secret? #22

Open smuda opened 5 months ago

smuda commented 5 months ago

From an operations perspective, we obviously treat secrets and configmaps very differently and try to avoid secrets where it's not needed.

I noticed that an issuer/clusterissuer points to a secret which contains the CA-bundle for communication with EJBCA. As CA-certificates are seldom confidential, what is the reasoning behind storing this as a secret?

m8rmclaren commented 5 months ago

Hi @smuda! Thank you for your observation regarding the storage of CA certificates in secrets. Initially, we stored both the client certificate and the CA bundle in secrets for simplicity, as they were both used in similar contexts.

Given that CaBundleSecretName is an optional field and considering that this API is still in its alpha phase (v1alpha1), there are two options that I'd love your input on:

  1. Add a new optional field called CaBundleConfigMapName in the v1alpha1 API, making it mutually exclusive with CaBundleSecretName
  2. Create a new version v1alpha2 where CaBundleSecretName is replaced by CaBundleConfigMapName.

Your feedback is greatly appreciated!

smuda commented 5 months ago

That depends on how many are currently using the current schema. Speaking only for myself, once we put this in production the schema name will be in numerous gitops repositories and we wouldn't like changing that in all places but that's not where we are right now.

The code would be simpler with option 2, so if there are not that many users yet, I'd go with option 2. If you think there are a lot of users, I'd go with option 1 and drop CaBundleSecretName in v1alpha3 instead.

smuda commented 4 months ago

Is there anything I can do to move this issue forward?