4 ms·

Theoretically, you could have a dump of staging data that your prod script could read and use. What’s key here is recognizing that staging and prod don’t have t

Theoretically, you could have a dump of staging data that your prod script could read and use. What’s key here is recognizing that staging and prod don’t have to talk to each other or be trusted, as such. Instead, what’s trusted is the deploy script, and your system is only as weak or as strong as the code used to deploy the deploy jobs. There aren’t many good answers here because you can fat-finger a security bug or data wipe, or have a bug that only presents itself in certain states. Or is created by human input. This quickly devolves into the “trusting trust” problem. Is my paranoia worse? ;-) I’d suggest monitoring all the things, and doing as much code review and fuzzing as you can afford... what normally improves your code and processes will probably help prevent security defects too.

lifeisstillgood 7y ago
I don't think dumping production secrets to anywhere qualifies as a good idea I am going to guess this is comparing the key part of key value stores - I regularly add a new configuration value to dev and wonder for hours why pre-prod is failing somehow i am missing the details and in this kind of case details is all that matters
- lstamour 7y ago
  Comparing keys is interesting, it’s a way of versioning the set of credentials you’re using. Here I meant dumping staging values and then comparing prod values as retrieved to staging ones. As in, only compare values in prod as they are used by a deploy script or system configuration tool. That said, if you have one server, one place where secrets are kept, then it’s probably safe enough to send non-prod secrets to servers as a way of ensuring the secrets are invalid. Meaning, you don’t actually need to know the prod secrets to test staging or known weak secrets against prod. That said, if in practice your secrets are randomly generated as services deploy, you’ll likely need to validate by observed behaviour rather than using hard-coded credentials. And if you’re practicing blue/green deploys, then staging might be just as production as prod...

lifeisstillgood 7y ago

I don't think dumping production secrets to anywhere qualifies as a good idea I am going to guess this is comparing the key part of key value stores - I regularly add a new configuration value to dev and wonder for hours why pre-prod is failing somehow i am missing the details and in this kind of case details is all that matters

lstamour 7y ago
Comparing keys is interesting, it’s a way of versioning the set of credentials you’re using. Here I meant dumping staging values and then comparing prod values as retrieved to staging ones. As in, only compare values in prod as they are used by a deploy script or system configuration tool. That said, if you have one server, one place where secrets are kept, then it’s probably safe enough to send non-prod secrets to servers as a way of ensuring the secrets are invalid. Meaning, you don’t actually need to know the prod secrets to test staging or known weak secrets against prod. That said, if in practice your secrets are randomly generated as services deploy, you’ll likely need to validate by observed behaviour rather than using hard-coded credentials. And if you’re practicing blue/green deploys, then staging might be just as production as prod...