Feature: Use ownerReference on secrets

[applejag]

By setting ownerReference on the secrets pointing to the source ClusterSecret Custom Resource adds a coupling that is both useful when just looking at the YAML of a secret, as well as then the operator could offload the deletion of secrets when the parent ClusterSecret is removed to the kubernetes built-in APIs.

The ownerReference field can also be added on existing objects, so the secrets wont have to be recreated when adding this feature, only updated.

[applejag]

Just found out that ownerReferences can only target stuff in the same namespace.

Which brings up a question, why is the CRD namespaced? All other Kubernetes resources that have the Cluster- prefix are cluster-scoped instead of namespace-scoped. Was this a conscious decision?

[zakkg3]

Hi Jillie
Not sure what would the adv to make the CRD cluster scope? security and isolation wise its not the same. do we want that?

[applejag]

Hmm this made me think.

Pro namespace-scoped:

• Usage in clusters where e.g teams have their own namespaces and the setup don't let the different teams step on each other's toes. That would require one operator installed per namespace, but at least the RBAC on the service account that ClusterSecret operator uses could be restricted.

Pro cluster-scoped:

• Supports ownerReferences to offload GC to kubernetes
• Follows expectation/convention of "ClusterX" resources to be cluster-wide

Yea the security functionality vs conventions is an obvious win to the former.

(Maybe a name such as SyncedSecret could be more appropriate?)

However the namespace-scoped RBAC use case should probably be documented, as I could assume an easy misconfiguration would be to have 1 global ClusterSecret operator, but then try to lock down creation of ClusterSecret CR to the namespaces. The ClusterSecret could then be used to steal secrets from other namespaces you otherwise wouldn't have access to. Having multiple operators running is clunky, but it's as far as I can tell the only option for such a usecase. Would need some way to not make multiple operators step on each other's toes then as well though.

Tricky topic!