ReferenceGrant

Why#

A Release can refer only to objects in its own namespace. The apiserver rejects a reference to another namespace, because a Cluster or a source can hold credentials. See Same-namespace references.

This rule stops these setups:

• One namespace holds the Cluster objects, and teams in other namespaces deploy to them.
• One namespace holds shared sources, and Releases in other namespaces use them.
• A Fleet in one namespace uses clusters or templates in other namespaces. See Tenancy.

Decided#

1. A namespaced object in the target namespace gives consent: Releases from a given namespace can refer to a given kind in this namespace. The owner of the objects that hold the credentials makes the decision.
2. convoy uses this model, not SubjectAccessReview. With a SubjectAccessReview, each user who refers to a Cluster or a source must have read access to it, and thus to its credentials. A grant gives permission to refer to an object, not permission to read it.
3. The controller checks the grant at each reconcile, not the apiserver at admission. A reconcile has no user identity, so it cannot do a SubjectAccessReview.
4. Cross-namespace fleets need this model.

Not designed#

• The API shape: the fields, and how a grant matches the source namespace, the kind and the name.
• The references that a grant covers. The same-namespace rule covers spec.clusterRef, spec.source.gitRepository, spec.source.helmRegistry, spec.source.ociRegistry, spec.content.helm.values[].gitRepository and mutations[].from.
• The behavior of a running Release when a user deletes its grant.
• The conditions and reasons that report a missing grant.
• How a grant works with Fleet.