[drey]

Summary

Adds a namespace-scoped resource family so a namespace owner can install a Helm chart without cluster-wide rights: five new CRDs (HelmApplication, HelmApplicationRepository, HelmApplicationChart, HelmClusterApplicationRepository, HelmClusterApplicationChart) and their controllers. The existing addon code is generalized rather than copied — both families now run through the same reconcilers.

Why

Installing a chart required cluster-admin, because every resource the module owns is cluster-scoped. A namespace owner needs a way to install charts in their own namespace without gaining access to the whole cluster.

Two requirements shaped the design. A release must be applied under a bounded identity, or a chart carrying a cluster-scoped object would escape the namespace boundary. And the new family must not become a second copy of the addon code, which lives on just as long and would have to be edited in both places.

Key changes

API (api/v1alpha1, api/naming, crds/). Five new CRDs with their Russian doc counterparts. RepositorySpec/RepositoryStatus and the chart catalog status are now shared types: all eight CRDs generate byte-identical to before, except one description line in the addon catalog. The catalog naming scheme moved to api/naming and became injective: the hash now covers the repository and chart joined by a byte no name can hold, so two pairs can no longer produce one object name.

Controller (images/operator-helm-controller/internal). Domain contracts in internal/source (repository, catalog, release, access) with a per-kind adapter in internal/adapter. The catalogs collapsed into one generic internal/catalog package, and the repository and release reconcilers are now shared. Adds controllers for the five new kinds and a HelmApplication webhook. A transitional step renames existing catalog objects to the current scheme on every repository reconcile, independent of the remote, carrying their status over before the old object is deleted.

Release identity (internal/services/access_service.go). Each application gets a token-less ServiceAccount in d8-operator-helm, a Role seeded in the application's namespace with full rights inside it, and a RoleBinding. The Role is created once and never read back, so a namespace owner may narrow it afterwards. The internal HelmRelease carries spec.serviceAccountName and spec.storageNamespace, and the release storage lives in the application's namespace.

Chart values service (images/chart-values-controller/internal). A repository kind is described by one family value instead of branching. The HTTP contract gained a namespace field, and authorization is decided per family: permission to create a HelmClusterAddon for addons, permission to create a HelmApplication in the requested namespace for applications. The namespace is part of a chart's identity only for a namespaced family; for a cluster-scoped one it is only the authorization context. Auxiliary object names now key on the repository namespace, and the cluster-scoped name shape is unchanged.

Templates (templates/). RBAC for both controllers, the webhook configuration and the ValidatingAdmissionPolicy cover the new kinds. The controller's rights over roles are narrowed to create, escalate and bind, since the Role is only ever seeded and never read back. Seven user-facing ClusterRoles are added for both Deckhouse role models, so a namespace owner can reach the new kinds at all: write access sits at admin level, the controller-written chart catalogs are read-only, and the cluster-scoped repository stays with cluster editors. The admission policy now also closes the application and application-repository statuses, which the seeded Role can otherwise reach.

Tests and docs. New e2e suites helmapplication and helmapplicationrepository. The derived-name scheme is mirrored in tests/e2e/internal/naming (the operator's internal package cannot be imported) and tied to the operator's own implementation by twin tests. README and EXAMPLE in both languages describe the new family and correct the claim that cluster-admin is required. CI gained a unit-test workflow and a generated-files check, and the Go lint job is enabled again now that the linter is built from source rather than downloaded.

Review focus / risks

• Every chart catalog object is renamed, the released addon ones included. The name a repository and chart pair produces was not injective, so two repositories could fight over one catalog object; the hash now covers the pair joined by a byte no name can hold. Existing objects therefore move. On the first reconcile after the upgrade each repository recreates its catalog objects under the new name, carries the old status over — a version a consumer still holds keeps its RemovedFromRepository marker and media type — and deletes the old object. The rename runs before anything touches the remote, so a repository not yet due for a sync, or one whose registry is gone for good, still migrates. Everything about it is marked TRANSITIONAL and comes out once every cluster has reconciled once: MigrateNames in internal/catalog/catalog.go, its interface entry, and Inputs.MigrateErr.
• Impersonation is never actually exercised. The tests confirm serviceAccountName and storageNamespace are set, but the werf/3p-helm-controller fork holds full rights itself: an implementation honouring the storage namespace while ignoring the service account would pass every check in this branch. Proving it needs a chart containing a cluster-scoped object and an assertion of Ready=False with forbidden. This is the one load-bearing assumption no test closes.
• Creating a HelmApplication is effectively namespace-admin. The seeded Role grants */*/* within the namespace. It is a deliberate decision, documented, but worth confirming the boundary is acceptable.
• The user-facing roles rest on review alone. Seven ClusterRoles cover both Deckhouse role models. Nothing checks them automatically: the module linter skips templates/rbacv2/** entirely, its wildcard rule only reads files named rbac-for-us.yaml, and its classic-model rule verifies the name and the access-level annotation but not the rules. No e2e exercises the aggregation chain either. Worth reading the labels against the upstream selectors by hand, in particular that write access lands at admin level and never at an editor one.
• The released addon family. No expectation changed in the thirteen addon test files touched; conditions, reasons, requeues, finalizers and the HTTP contract match. Three deliberate differences: catalog object names move as above, an addon release name longer than 53 characters is now truncated instead of being rejected by Helm, and three catalog error messages were reworded. Every other derived name is frozen and pinned by a test.
• The namespace divergence for helmclusterapplicationrepository. The request must carry a namespace and is authorized against it, but the namespace is dropped when the chart is resolved. Worth confirming the divergence is genuinely not exploitable.
• Repository isolation is only partly proven. The e2e creates same-named repositories in two namespaces but with the same URL, so their chart sets coincide: a controller pruning objects by label without a namespace restriction would still pass that test.