[ejcx]

While this is true, it's something you can work with in the future, and it defined a secrets process earlier rather than later

If you do nothing you end up stuck with secrets in git history and you essentially have to roll them all.

So, my advice is generally SSM with no security is better than no secrets Management solution.

[eropple]

If you do nothing, you end up with secrets manually provisioned by logging into a machine and splatting out a configuration file. Which is a more secure solution than a turtles-problem parameter store.

[ejcx]

You're assuming readers are managing snowflake servers, and I'm assuming they are in an containerized/autoscaling/more modern environment.

SSM wins for mine. I think you're right that the file approach wins for yours.

[eropple]

I'm assuming readers are just starting out, where auto-scaling and bloggable container architectures make very little sense. Configuration management is a prerequisite for those. That said, having a CM in place also makes the please-invest-in-us container ecosystem much less attractive, given that you can easily fall back to singleton-container-on-an-instance patterns (which is a great one for deployment regardless of your approach).

To that end, yes, their servers are probably hand-rolled or provisioned with minimal scripting like Ansible. And so manual secret deployment is to be expected.

If somebody is attempting to autoscale without having this solved already, they are making mistakes.

[dboreham]

“Bloggable” LOL