Something I don’t understand. How is keeping all your passwords in encrypted in one vault with a plain text password all over your system, any better than keeping than keeping plain text passwords all over the system? If someone has access to your system they’re getting your passwords either way.
How is keeping all your passwords in encrypted in one vault with a plain text password all over your system
This setup would work like this:
Configuration management software runs on the box and executes a task/playbook/recipe/… that needs a secret
The configuration management system reads a central plain text password which is locked down to root only.
The configuration management decrypts the vault and puts the secrets on the box, according to how the task is programmed - hopefully writing to a locked down configuration file ;)
The intent is to first prevent someone who isn’t on the box from getting secrets - think developers grepping over repositories - but it’s possible to extend it further to protect secrets from people on the box.
For something like this to work successfully, you must ensure control over the secret key, and should also use some sort of least-privilege access to secrets.
Getting the key in place is easy - bake it into a master VM, or set it at provision time.
Controlling it means locking it to root and ensuring you have a controlled sudo environment, and not everyone can just sudo -i. I’ve seen configurations that try to set up permissible commands, but it’s far easier to tell people “your VM is a VM appliance, you don’t get root”. If you can get away with that, life is better :)
Ensuring restricted access is far easier. If you spin one vault up for VM class - say, a web server VM & vault, a DB VM & vault, whatever else - you can set the secrets accordingly and greatly restrict the blast radius if a compromise happens.
This isn’t hard to do, nor is it particularly difficult, but it gets painful if you don’t treat your VMs as ephemeral things.
Amazon’s IAM gets criticism for complexity, but once you dig in a bit this becomes trivial - secrets go into KMS, EC2/ECS/Lambda (!!) get an IAM role attached that allows them to decrypt with only one key, and then you can assume the role to decrypt the secret. And that’s if you’re stepping outside the AWS ecosystem; otherwise, KMS wouldn’t even be needed.
Something I don’t understand. How is keeping all your passwords in encrypted in one vault with a plain text password all over your system, any better than keeping than keeping plain text passwords all over the system? If someone has access to your system they’re getting your passwords either way.
This setup would work like this:
The intent is to first prevent someone who isn’t on the box from getting secrets - think developers
grepping over repositories - but it’s possible to extend it further to protect secrets from people on the box.For something like this to work successfully, you must ensure control over the secret key, and should also use some sort of least-privilege access to secrets.
Getting the key in place is easy - bake it into a master VM, or set it at provision time.
Controlling it means locking it to root and ensuring you have a controlled
sudoenvironment, and not everyone can justsudo -i. I’ve seen configurations that try to set up permissible commands, but it’s far easier to tell people “your VM is a VM appliance, you don’t get root”. If you can get away with that, life is better :)Ensuring restricted access is far easier. If you spin one vault up for VM class - say, a web server VM & vault, a DB VM & vault, whatever else - you can set the secrets accordingly and greatly restrict the blast radius if a compromise happens.
This isn’t hard to do, nor is it particularly difficult, but it gets painful if you don’t treat your VMs as ephemeral things.
Amazon’s IAM gets criticism for complexity, but once you dig in a bit this becomes trivial - secrets go into KMS, EC2/ECS/Lambda (!!) get an IAM role attached that allows them to decrypt with only one key, and then you can assume the role to decrypt the secret. And that’s if you’re stepping outside the AWS ecosystem; otherwise, KMS wouldn’t even be needed.
Great answer! +1
How does one actually secure that plain text password though? Is there more you can do than just using chown and chmod?
It can be configured to be provided at every run if you wish.