Move Project configuration into a single namespace-scoped resource

[jessesuen]

Proposed Feature

This is a proposal to introduce a new namespaced-scope CRD, ProjectConfig, where all Project configuration would live, including the current promotionPolicies. By moving configuration into a namespaced-scope resource, it would enable self-service and more granularity of who can edit project configurations (e.g. promotion policies, and future settings).

Motivation

Currently, project configuration (currently only promotionPolicies) are stored in the Project CRD. The challenge is that because Projects are a cluster-scoped resource, only a cluster admin can edit projects. This makes it awkward (though not impossible) to grant access to edit a single Project.

We want a more fine-grained ability to control projects. e.g. there should be the ability for user A to edit project configuration for project-a, but not for project-b.

As I alluded to, this can technically be solved with current kubernetes RBAC using ClusterRoles that specify resourceNames, e.g.:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kargo-project-a-admin
rules:
- apiGroups: kargo.akuity.io
  kind: Project
  resourceNames:
  - project-a

However, the above approach is not ideal. The ability to create this ClusterRole and ClusterRoleBindings, in and of itself, requires cluster privileges. Many things would become simpler, and possible, if project configuration were namespaced scoped.

Suggested Implementation

Whenever a Project is created, along with its corresponding Namepsace, we would immediately create a ProjectConfig in the project namespace, called default. This would be similar to how the default ServiceAccount is created in every namespace. The default ProjectConfig is where Kargo would look for all project configurations, such as promotion policies.

We would then enhance our existing, kargo-admin Role, to have update patch privileges to the default ProjectConfig.

NOTE: Despite this being a namespaced scope resource, other ProjectConfig resources not named default would be ignored. There would never be a reason to give create or delete privileges on ProjectConfig resources since our controller would automate the creation of them, and deletion would only be needed when the Project/Namespace is deleted (already handled by cascaded deletion).

[hiddeco]

Playing advocate of the devil here, but I think it is worth it to at least have this documented for historical purposes.

Is there any specific reason we maintain these configuration at Project level instead of trying to incorporate these options into e.g. Stage or Warehouse resources themselves? Especially given we do (still) only have a single option at this level, that simultaneously does not make it clear auto-promotion is allowed when viewing (or working on) a particular Stage.

One reason I can think of myself is indirectly provided in #3670 (define once, apply to many) — but that does not hold true at this point.

[krancour]

Is there any specific reason we maintain these configuration at Project level

Yes. It's for things that are off limits to other relatively privileged users for a given Project.

Consider a "developer" who is authorized to update Stages but not perform promotions. If something like auto-promotion being enabled/disabled were controlled at the Stage-level, a developer could effectively do the equivalent of manual promotion to a Stage without auto-promotion by enabling that option.

At the moment, we're only using this to enable/disable auto-promotion, but we will presumably find other things that fall into this category of "only the Project admin should touch."

[BenHesketh21]

I'd be interested in working on this if we are happy with implementation and it's not needed urgently.