I’ve initially integrated Doppler through the external secrets operator (ESO). In general this works pretty well, but I was missing the option to redeploy deployments when a secret value changes. I noticed the Doppler secrets operator (DSO) does support this feature but lacks other features, which doesn’t allow me to use the same implementation.
With ESO I’m able to pick certain fields from a Doppler project. For example in the case of a MariaDB database I would have secret only reference the MARIADB_ROOT_PASSWORD field. This allows me to reuse the same Doppler project for multiple k8s secrets. DSO doesn’t seem to have this capability. Afaik it will sync all secret fields.
This gives me the impression that I would have to create a separate configs per k8s secret if I were to use DSO? I guess this could be implemented in one of the following ways:
Project per secret (e.g. service-A-mysql)
Env per secret (e.g Project: service-A, Env: mysql-prod)
Branched config per secret (e.g Project: databases, config: stg_service_a_mysql)
Is my assumption correct. If so what is the recommended approach here?
You have a couple options here. First, you can get similar functionality to the automatic redeploy our own operator does by using something like Reloader. If that works for you, for now that may be the best option for you. In the future, we plan to add more functionality to our operator, so it may remove the need or make it more desirable to switch over, but until then this might be the easiest course.
As far as the implementation options you were considering, I would probably go with moving your MariaDB credentials out into a separate project and then use secret referencing to add them back into any other places you need. Then, when you only need those specific secrets, you can sync from this project directly. Alternately, your third option wasn’t a bad one either. The only pitfall is that after you create the branch config and remove all the secrets you don’t want – it will still inherit new secrets added to the root config. So, whenever you add a new secret in the root config you’d have to remove it from all the branch configs you don’t want it in. That being the case, probably a separate project would be best. You could then have a databases project that contained all the individual database secrets in aggregate using secret referencing if you so desired.
