(One of my summaries of a talk at the 2020 online devopsdays Amsterdam conference).
Three people can keep a secret if two are dead.
Secrets? Private certificate keys, username/password, etc. You need to keep them secret in order to protect assets. Personal info, medicial info, financial, system configs, protecting your servers from cryptomining, etc. Also logs need to be protected (otherwise you’re handing intruders a map).
What needs to consume the secret? One service? Multiple ones?
How is the secret stored? Keepass? Source code?
How is the secret rotated? How often?
How do you initially generate the secret? How do you keep it secret?
How do you keep humans from seeing machine secrets?
If you have multiple systems (cloud…), how do you move the secret?
Problems: lots of secrets all over the place. There’s often no centralised solution. Secrets can be hardcoded in software. Default passwords (equifax’s admin:admin…).
Luckily, there are tools for that. But first, we need to look at policies. Take an inventory of what you’re doing now. Which secrets do you have? How are they stored? Who has access to what?
Principle of least privilege. Only give the bare minimum of privileges that allows the user to complete the job.
She then did a demo with hashicorp vault and kubenetes. Also there, the principle of least privilege is important. Who needs access to which secrets? Write access? Read access?
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
