Shouldn't allow DopplerSecret in another namespace access `doppler-operator-system` namespace secrets

[NOBLES5E]

It is a big security flaw. You are giving anyone that can create a DopplerSecret resource in any namespace access to all the secrets! I feel so freaking out when I find it works in that way 😿

[nmanoogian]

Hi @NOBLES5E, thanks for bring this to our attention! You're right that the operator does allow users who can create DopplerSecret resources in any namespace to pull secrets from any token secret in the system. For example,

• You have app1 and app2 namespaces
• You install the Doppler operator, which adds the doppler-operator-system namespace
• You create a token k8s secret containing your service token at doppler-operator-system/doppler-token-secret, as we recommend in our docs
• You create a DopplerSecret at app1/doppler-secret-1 which references doppler-operator-system/doppler-token-secret and managed k8s secret app1/k8s-secret-1, the operator syncs the data to the managed secret
• You create a DopplerSecret at app2/doppler-secret-2 which also references doppler-operator-system/doppler-token-secret, and you specify managed k8s secret app2/k8s-secret-2, the operator syncs the data to the managed secret

As a result, app2 was able to access doppler-operator-system/doppler-token-secret (and use the operator to fetch the underlying secrets) just by being able to create DopplerSecret CRDs -- even though it was created/owned by app1.

We initially intended that your clusters would be configured such that only privileged users can create DopplerSecret resources but I certainly see how it would be concerning and unintuitive to have resource creation as the gate for access to all Doppler-based secrets in your cluster.

I think a better approach here would be to require that the token k8s secret, DopplerSecret resource, and managed k8s secret must all exist in the same namespace. This will silo all data to each namespace. Does this solution sound like it would meet your requirements?