Cross namespace secrets/resourcegroup scenario

[wasabii]

From a question I asked on Slack, to which @theunrepentantgeek replied.

I'm trying to come up with a setup to have a "manager" app which creates resource groups and an identity, and then creates the secret for the identity, and hands it to a second K8s namespace, for resources in that namespace to use that resource group.

Basically I don't want the individual namespaces to have permissions to CREATE groups, just create resources inside them. But I'm finding that difficult.... the manager can create the resource group.... in its own namespace. As well as the user identity, in its own namespace..... and operatorSpec can create the secret from the identity.... but not in the second namespace.

And then the second issue, which is that you can't reference Resource Groups (or anything) cross namespace. So, I'd require either to use an ARM ID in the child namespaces, or have two RG entities, with one with detach-on-delete. But the detach on delete would probably need to be in the child, and thus enforced by the child.

A solution to the first issue would be to be able to optionally specify the namespace for a SecretDestination. And then the requisite security considerations around that.

A solution to the second would be to allow cross namespace owners.

It's possible both of these things will hit the same issue: security.

But the strict prohibition against cross-namespace stuff kinda makes delegation of things like this hard.

[matthchr]

Things we should look into:

1. What security guarantees do other tools like reflector give - do they have configuration that would make this safe (or safer at least)?
2. Could we add an option in ASO that defaulted to off, but allowed cross-namespace writes of secrets (and maybe configmaps).
3. Could we have any additional security checks, such as actually checking RBAC to avoid priv escalation? I know we've looked at this before and it's very difficult due to possibility of multiple writers, including those like Flux/Argo.

Regardless of which of the above options we end up suggesting folks use, we want to make sure we understand the security implications/risks of allowing cross-namespace writes.

[matthchr]

Hoping that we can design this some in 2.13.

[matthchr]

Related to #1398