limit-namespaces for namespace-scope deployments

[hubeadmin]

Implement the limit-namespace argument for the manager, this enables the manager to run in a namespace-scoped configuration.

This allows users in constrained OpenShift environments, such as those running multi-tenant clusters, a more convenient deployment method, without running into permission issues, and eventual crash looping due to inadequate RBAC.

By default, the implementation will retain cluster-wide configuration. If the --limit-namespaces argument is passed with a list of comma-delimited namespaces, the manager will be configured to only list and watch resources within the provided namespaces.

Not sure if this is really useful for anyone else, but it is a change I had to implement for one of our internal deployments to work.

Without getting into too much detail, we have an internal cluster that serves a pretty large number of tenants. No tenant is allowed access to cluster-wide resources, and their permissions are scoped to only the namespaces owned by that tenant. This meant that we weren't able to user the openshift-routes cert manager as-is, as it was trying to request resources outside our tenant's scope, and as we weren't able to add the RBAC to make this work out of the box, we had to make this change.

[cert-manager-prow]

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.

📝 Please follow instructions in the contributing guide to update your commits with the DCO

Full details of the Developer Certificate of Origin can be found at developercertificate.org.

The list of commits missing DCO signoff:

• 634a830 limit-namespaces for namespace-scope deployments

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[cert-manager-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign erikgb for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cert-manager-prow]

Hi @hubeadmin. Thanks for your PR.

I'm waiting for a cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[hubeadmin]

📝 Please follow instructions in the contributing guide to update your commits with the DCO

Points to a 404

[ctrought]

No tenant is allowed access to cluster-wide resources, and their permissions are scoped to only the namespaces owned by that tenant. This meant that we weren't able to user the openshift-routes cert manager as-is, as it was trying to request resources outside our tenant's scope

Out of curiosity, I assume there is a reason why cert-manager and openshift-routes are not just deployed into their own dedicated namespaces outside of the tenants control, much like the openshift-* namespaces? Does that mean each tenant has their own deployment of cert-manager and openshift-routes, confined to their namespace(s)?

[hubeadmin]

No tenant is allowed access to cluster-wide resources, and their permissions are scoped to only the namespaces owned by that tenant. This meant that we weren't able to user the openshift-routes cert manager as-is, as it was trying to request resources outside our tenant's scope

Out of curiosity, I assume there is a reason why cert-manager and openshift-routes are not just deployed into their own dedicated namespaces outside of the tenants control, much like the openshift-* namespaces? Does that mean each tenant has their own deployment of cert-manager and openshift-routes, confined to their namespace(s)?

Exactly, as tenants we don't have access to openshift-* namespaces, but onboarding cert-manager and openshift-routes on a cluster level is more of a bureaucratic challenge than it is a technical one.
Albeit, our workload is special in terms of the SSL certs we use. Generally, every other tenant on that cluster would request a manual cert from our internal team to sign it with the company's domain, so it's not an issue for almost everyone else. However, the service we run is for an upstream community, as such we wanted to use letsencrypt with ACME after getting our route registered within their DNS. Installing it in our namespace wasn't a problem at all, but the cross-namespace listing was, as we started going into a crashloop due to high error rates, the request getting constantly rejected by inadequate RBAC. (And the cluster admins, to no surprise, didn't want us to get the permissions)