Earlier quoted context omitted.
ParameterStore lets you store String, StringList or SecureString. But there's no limit to SecureString. A SecureString can be `postgres://admin:hunter2@localhost:5432/db`. It can also be `{"username": "admin", "password": "hunter2", "host": "localhost", "port": "5432"}`.
Sure you could do that if you don't mind adding in your own string->dict conversion. I wouldn't be surprised if the internal implementation is near-identical. Secrets Manager seems like a slightly more easy-to-use version of Parameter Store that's also visible, instead of hidden away inside Systems Manager.
AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
101–110 of 137 posts
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#102At $0.40 per secret per month and $0.05 per 10,000 requests this is much more expensive than the practically free SSM Parameter Store product, even if you factor in the auto-rotating bits.
It'd be cheaper than running Vault with a backing Consul cluster which also provides rotation and other features. There is a point where Vault is more cost effective, but I believe it'd require a ton of requests and secrets to justify min 6 machines of at least t2.micro that also need to managed and secured.
With Vault 1) you have to get Hashi Enterprise 2) Pay for a very pricey HSM.
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#103Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#104Earlier quoted context omitted.
Wait, you keep private SSH keys on bastion hosts? It's much better practice to use the bastion as a proxy to the other hosts. This is easily achieved using the ProxyCommand option of OpenSSH. No agent forwarding, no secrets kept in random hosts.
Do you know a good guide with standard practices for setting up and securing bastion hosts (preferably on aws)?
I’m currently deploying it in an enterprise for ~5k users, and it works surprisingly well for providing the ability to run arbitrary commands on instances without ssh access.
[1] https://docs.aws.amazon.com/systems-manager/latest/userguide...
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#105Earlier quoted context omitted.
What are you assuming about exposure? If a SSH key lives on a well-secured workstation or bastion host (and you ideally don't agent-forward it to insecure hosts), rotating that key once per hour doesn't seem a top priority to me? E.g. a sudo password is (lower-impact, but) more likely to get exposed to compromised hosts? ("Well-secured workstation" is arguably an oxymoron, of course...)
Wait, you keep private SSH keys on bastion hosts? It's much better practice to use the bastion as a proxy to the other hosts. This is easily achieved using the ProxyCommand option of OpenSSH. No agent forwarding, no secrets kept in random hosts.
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#106Earlier quoted context omitted.
My biggest criticism of Parameter Store is actually that it's free. Let me explain: Because it's free they limit the requests per seconds you can make to the Parameter Store. That's especially noticeable when doing requests for all parameters of a given path, as the limit is way lower there than for requesting (a bunch of) individual parameters. In the past that caused serious problems for us when using Parameter Sto…
Oh, yeah, we just ran into this recently when rolling-out parameter store. For anyone else having this problem, the trick was to use the GetParametersByPath API method ( https://docs.aws.amazon.com/systems-manager/latest/APIRefere... ) instead of the more flexible DescribeParameters (which has stupidly low, undocumented rate limits).
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#107First reaction: Holy crap! They finally turned ParameterStore into a proper product! Second reaction: Holy shit that's expensive [for what it does]. ParameterStore is free (minus the KMS component). The only value-add is secret rotation and that's not something that most of the time makes sense to use. [Edit: I'm not advocating for no rotation; see replies] Edit: Had more time to think about it. Someone enlighten me:…
> The only value-add is secret rotation and that's not something that most of the time makes sense to use. From a security perspective, you should be rotating secrets somewhere between annually and every 90 days, depending on your business/security/compliance requirements and the nature of the data secured by the secret.
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#108This looks like an AWS equivalent of the Amazon-internal secret management tool called Odin. Which is very nice because Odin was pretty much universally loved from what I saw.
After leaving Amazon you really go on to understand how good the internal tools are at Amazon and how they probably have the best tools in the industry.
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#109Earlier quoted context omitted.
After leaving Amazon you really go on to understand how good the internal tools are at Amazon and how they probably have the best tools in the industry.
Brazil + Apollo + Pipelines. I left (and later boomeranged) and was surprised that the outside world hadn't solved these problems nearly as well. Don't get me wrong, Brazil and Apollo probably are ready for a rethink and rewrite, but they do a great job.
Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely
#110This looks like an AWS equivalent of the Amazon-internal secret management tool called Odin. Which is very nice because Odin was pretty much universally loved from what I saw.
After leaving Amazon you really go on to understand how good the internal tools are at Amazon and how they probably have the best tools in the industry.
Our team was abandoning Apollo for MAWS, so our deployments were bridged between the two, resulting in another twisted pile of incomprehensible script-glue.
Pipelines was ok (!)
Everything on public EC2 for managing deployments (CodeDeploy and CloudFormation in particular) were so broken and bug-ridden and non-performant that we couldn't reliably deploy production code with them.
I prefer open source solutions in almost every way. I actually can't think of a single problem that the Amazon internal stack solves that isn't better solved in the open-source world. Which isn't surprising, given the constraints involved.