Feature: per namespace trust bundle

[KLuuKer]

trafficstars

I have multiple namespaces that don't trust each other and have their own per namespace root ca

I would like to be able to specify a bundle per namespace instead of 1 for the whole cluster

This would also help with the cleanup when said namespaces get deleted

[erikgb]

This should already be possible using the field spec.target.namesspaceSelector: https://cert-manager.io/docs/projects/trust-manager/api-reference/#bundlespectargetnamespaceselector. To target a single namespace, you can achieve that:

spec:
  target:
    namespaceSelector:
      kubernetes.io/metadata.name: my-namespace

[ProbstDJakob]

But the bundle resource is still a cluster-wide resource and not bound to the namespace, thus will not be removed upon deleting the namespace. Furthermore you need permission to create cluster-wide resources and this is not possible if you can only manage specific namespaces.

[erikgb]

Could you please elaborate on your wish @ProbstDJakob? I am not sure if I understand what you are trying to achieve.

[ProbstDJakob]

It would be nice to have a ClusterBundle (the current Bundle) and a Bundle. Similar to ClusterRole and Role. Thus users with less privileges could create namespace bound Bundles for their projects and admin users could create ClusterBundels from which multiple namespaces at once could benefit (by injecting cert-bundle-configmaps). I hope it is now clearer what my wish is.

[erikgb]

Ok, thanks for the explanation. 👍 I think this use case will be hard to address, especially the multi-tenant dimension. I suggest you start by following issues that I consider blockers (or at least semi-blockers) for what you are trying to do: https://github.com/cert-manager/trust-manager/issues/60 (source namespace for trust CA) and https://github.com/cert-manager/trust-manager/issues/63 (naming; blocks creating a new namespace-scoped resource).

[ProbstDJakob]

Sorry for the late response, but thanks for the input. I have looked into both issues and issue #60 made me realize that I did not have thought about security (not allowing trust-manager to read all secrets in every namespace). I am not sure why or how cert-manager can access/create secrets without being able to read all other secrets, but maybe this approach could help solving the issue. Another possible solution could be to extend cert-manager to write the public keys to the Certificate resources' status which trust-manager than would be allowed to read from (thus not involving secrets at all).

[KLuuKer]

For me just being able to have sub CA and trust bundles (maybe signed by the cluster ca) would be enough It's more a per namespace security/trust thing then a fullblow tenant isolation

[karmops]

I didn't get this "trust" namespace because it drives/obligates me to have a different topology and view of this project.

1. I have a Redis with this; I want the projects(namespaces) that use this Redis to receive the ca.crt file over config-map or secret...
2. I have Kafka with TLS... same as above
3. I have a database with TLS... same above

I can't deploy this trust manager once and use bundles with different trust namespaces. To solve my scenario, I need to deploy it three times, one for each namespace(Redis, Kafka, and database). Is this what this project is expecting to be used for? Why this is not clear in the documentation?

I believe it should have a design (image) explaining these scenarios