stashed
Handling storage secret for BackupBlueprint
- [ ] Should operator copy storage secret from its own namespace into the
BackupConfigurationnamespace? Currently, users have to manually create the storage secret in theBackupConfigurationnamespace.
Hello,
This is a big deal for my company as I would like to create some kind of cluster-automated backups, leaving developpers with the choice to select a predefined Blueprint for their namespaced projects, without bothering with setting up the S3 configuration which is common to everybody.
So, if operator copy the storage secret from its own NS to the BackupConfiguration namespace, it'll allow automated backups to the same backend - but doesn't prevent namespace admins to read the copied secret (which is unwanted as the backend's credentials will leak all over the place).
The only solution I can think of is by creating some kind of restic proxy/gateway in the operator's NS (or wherever devs don't have access to the secrets), with the proxy/gateway providing the secret and authenticating BackupConfigurations.
It feels like a hack but some S3 gateways already exist. Maybe there's a more K8s native way for preventing secrets leaking which I'm not aware of.
Regards
Well, copying secrets automatically doesn't impose more security risks than current manual routine. The end result is always Secret in application owner's Namespace. So I would support this approach as first-aid solution that gives more automation with the same risks.
As long-term(-ish) solution I would explore the opposite to @r-mach 's method. Why not start BackupSession in "native" to operator, BackupBlueprint and Secrets' namespace and access targets like mongodb://mongo.my-app-namespace:27017?
There are two pitfalls with this solution:
- works only for "smart" backup targets aka databases, not PVCs (or does it?)
- would probably have problems in clusters with restrictive NetworkPolicies
