-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Description
The Signadot operator Helm chart currently hardcodes signadot as the
deployment namespace in 60+ places across 44 template files. This makes
it impossible to install the operator into any namespace other than signadot.
Problem
Organizations that enforce namespace naming policies — such as
{product}-{service}-{environment} conventions — cannot use this chart
as-is, because the signadot namespace name may violate their policies.
Specifically, the following resource types all hardcode namespace: signadot:
- Deployments, ServiceAccounts, Services, Roles, RoleBindings — resources are always created in
signadot - ClusterRoleBindings (
subjects[].namespace) — ServiceAccounts outside thesignadotnamespace cannot receive cluster-wide permissions - MutatingWebhookConfiguration (
clientConfig.service.namespace) — the webhook fails to reach the service when installed in a different namespace _helpers.tpl— thegetAllowedNamespaceshelper always appends"signadot"to the watched namespaces list
Proposed Solution
Add a namespace parameter to values.yaml (defaulting to "signadot" for
full backward compatibility) and replace all hardcoded references with a
template helper {{ include "operator.namespace" . }}.
Default behavior (unchanged):
helm install signadot-operator signadot/operator \
--set controlPlane.clusterToken=$CLUSTER_TOKEN
# Resources still deployed to "signadot" namespace
Custom namespace:
helm install signadot-operator signadot/operator \
--set controlPlane.clusterToken=$CLUSTER_TOKEN \
--set namespace=<custom-namespace>- Additional Notes
The template files contain # This file is generated. Do not edit. comments.
If there is an upstream generator, changes may need to be applied there.
Please advise if a different approach or location is preferred.