Closed NOBLES5E closed 2 years ago
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,
app1
and app2
namespacesdoppler-operator-system
namespacedoppler-operator-system/doppler-token-secret
, as we recommend in our docsapp1/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 secretapp2/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 secretAs 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?
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 😿