FAQ

What are the Dev, Ops, and Security journeys for secrets management?

Different personas have different responsibilities at each level of the Vault maturity model. Learn what they are.

Speakers

Transcript

As we look at the crawl, walk, run of Vault adoption, there are different personas involved in each of those, and each of these personas, it's important that they're working together. They're not working in silos, but they're collaborating across what it is that they're trying to do.

Crawl

If we look at the crawl journey, say we're just trying to centralize those secrets. Well, it takes the developers to be able to identify where in the version control systems those secrets may lie. It takes the operations team to actually stand up Vault and enable those KV secret engines so that the developers can put their secrets in there. Then of course InfoSec and your security teams to ensure that the governance that you put over those—the ACLs (Access Control Lists) that you apply to who can access what—is in line with the way that they've had it set up in the past. So, that way when all teams are collaborating, you can centralize your secrets but everyone is comfortable with this new solution that can better integrate with modern infrastructure automation tooling.

Walk

As you go into the walk journey, there are different methods that you'll need to use to securely introduce those secrets. Your operations team can certainly help with providing secrets that just live on the box and are there by the time the application shows up—ensuring that the developer team and the operations team are working together on: how quickly do you want to get this application into a better state?

Can the operations team help with providing those secrets at the time a box is stood up? Or with the orchestration tooling that they've provided—maybe a Kubernetes maybe a Nomad—can they just inject those secrets into the place that that application is already going to be and all the developer has to do is know to look there? By working closely together as a developer team and an operations team, you can find the easiest way to start to secure your applications in a better way.

Run

Moving into the run portion, there are more aggressive TTLs (Times to live) in your dynamic secrets and what we're really trying to do is ensure that we provide ways for developers to easily encrypt all of their data. Common API endpoints, ensuring that the ACLs are associated with who is accessing what is tightened up in a way that maybe they can only encrypt and only operators can decrypt, or you can segment or silo the different applications as to who can do what. So, again through every step of the journey the more that each of these teams collaborate and they're able to talk about what their challenges are and what their goals are, the more you're going to get out of a secrets management solution, and then the less secret management solutions that you're going to need.

More resources like this one

  • 4/11/2024
  • FAQ

Introduction to HashiCorp Vault

Vault identity diagram
  • 12/28/2023
  • FAQ

Why should we use identity-based or "identity-first" security as we adopt cloud infrastructure?

  • 3/14/2023
  • Article

5 best practices for secrets management

  • 2/3/2023
  • Case Study

Automating Multi-Cloud, Multi-Region Vault for Teams and Landing Zones