Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow all resources to be namespaced #297

Open
chiqomar opened this issue Feb 16, 2024 · 5 comments
Open

Allow all resources to be namespaced #297

chiqomar opened this issue Feb 16, 2024 · 5 comments
Labels
priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@chiqomar
Copy link

We have a relatively unique set up. that until multiple namespaces are enabled, this may be a better solution.

Requirement:

We need to deploy trust-manager in a manner all the trust-manager resources are fully namespaced, or in a way that any deployments in other namespaces would not interfere with a deployment in another namespace.

Why?

The environment that we are deploying to only gives us access to a single namespace that we deploy to using Helm; we do not have access to the cert-manager namespace, and it is more ideal for us to deploy trust-manager as part of our namespace until it can support multiple namespaces (even if it could, we don't know how reconfiguring trust-manager for other namespaces after deployment would work).

Current Solution

I am using trust-manager as a dependent chart in our parent Helm chart, disabling CRDs, and have an edited Bundle CRD in the parent chart that is scoped to the namespace.
What I realize is that 3 resources will prevent deployments in other namespaces: validatingwebhookconfiguration,,clusterrole, and clusterrolebinding. So even if we deploy to our namespace, it will currently prevent other deployments.

Proposed Solution

  • Add a configuration value boolean namespacedOnly, which will allow for a fully namespaced deployment
  • If enabled, clusterrole and clusterrolebinding won't be installed (not sure if this is an issue), or the name will include a reference to the namespace it is in, i.e. trust-manager-user-dev
  • The validatingwebhookconfiguraton would follow the same naming convention if enabled

Alternatively, configuration for multiple namespaces should be completed, and we can work around that.

@inteon inteon added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Aug 29, 2024
@RobKenis
Copy link

RobKenis commented Nov 8, 2024

I am running into a similar issue where I want to manage Java keystores per namespace.
Ideally I can put some ConfigMaps in a namespace and reference them in the Bundle, but currently the ConfigMaps have to be placed in the cert-manager namespace.
Is there a reason to manage the Bundle as a global resource? cert-manager has the distinction between Issuer and ClusterIssuer. Can trust-manager do the same thing for Bundle and ClusterBundle? The current solution is hard to use in multi-tenant environments, since you are forced to put namespace specific configuration in the cert-manager namespace.

@erikgb
Copy link
Contributor

erikgb commented Nov 8, 2024

Another open issue suggests renaming the current Bundle kind to ClusterBundle: #63. That could make room for a new namespaced bundle resource.

@RobKenis Why would you want to use trust-manager in your use case? Why not reference the configmap directly? Trying to understand. 🤔

@RobKenis
Copy link

RobKenis commented Nov 8, 2024

@erikgb I have en application where users can upload certificates themselves. Currently there are some scripts to add those certificates to a keystore, but trust-manager would simplify this process. Since I'm already using cert-manager in the cluster, it seemed like the most logical solution.

@erikgb
Copy link
Contributor

erikgb commented Nov 8, 2024

Ahhh, so you want use trust-manager to convert certs in PEM format into a truststore?

@RobKenis
Copy link

RobKenis commented Nov 8, 2024

@erikgb Correct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

No branches or pull requests

4 participants