Introduction to HashiCorp Vault with Armon Dadgar

HashiCorp
23 Mar 201816:52

Summary

TLDRThe transcript discusses Vault, a solution for secret management, addressing the problem of securely handling credentials like usernames, passwords, API tokens, and TLS certificates. It highlights the issue of secret sprawl, where secrets are scattered across infrastructure, and emphasizes the need for centralized, encrypted storage with fine-grained access control and audit trails. Vault offers dynamic secrets, reducing the risk of credential leaks, and provides encrypt-as-a-service for better key management, ensuring correct cryptography implementation and offloading key management tasks. The architecture of Vault is highly pluggable, supporting various authentication backends, audit backends, and secret backends, allowing for flexibility and scalability.

Takeaways

  • πŸ”‘ Vault is designed to solve the secret management problem by centralizing the storage and control of various credentials like usernames, passwords, API tokens, and TLS certificates.
  • 🌐 The concept of 'secret sprawl' refers to the uncontrolled distribution of secrets throughout an infrastructure, often in plaintext, leading to security vulnerabilities.
  • πŸ”’ Vault encrypts all secrets both at rest and in transit, ensuring that even if access is gained, the secrets are protected and unreadable without proper decryption.
  • πŸšͺ Fine-grained access control allows Vault to limit which credentials are accessible to specific clients or users, preventing broad and potentially dangerous access to sensitive information.
  • πŸ“‹ Audit trails in Vault provide visibility into the usage and handling of credentials, allowing for accountability and the ability to trace any misuse or leaks back to their source.
  • πŸ”„ Vault supports dynamic secrets, issuing short-lived, ephemeral credentials to applications, reducing the risk of long-term exposure if credentials are compromised.
  • 🎯 Each dynamic secret is unique to the client it's issued to, allowing for precise identification and isolation in the event of a security breach.
  • πŸ›‘οΈ Vault's encrypt-as-a-service feature offloads the responsibility of cryptography from applications, ensuring that encryption and decryption are handled correctly and securely.
  • πŸ”§ Vault's architecture is highly pluggable, with authentication backends, auditing backends, and storage backends that can be customized to fit various environments and use cases.
  • 🌍 For high availability, Vault instances can be run in a cluster with a shared backend, using leader election to ensure that requests are always processed by an active node.

Q & A

  • What is the primary problem that Vault aims to solve?

    -Vault primarily aims to solve the secret management problem, which involves securely managing and controlling access to various credentials such as usernames, passwords, database credentials, API tokens, and TLS certificates.

  • What are some challenges associated with secret sprawl?

    -Challenges with secret sprawl include the difficulty of knowing who has access to the secrets, the lack of an audit trail to track usage, and the complexity of rotating secrets when they are hardcoded in source code or scattered across multiple systems.

  • How does Vault address the issue of fine-grained access control?

    -Vault addresses fine-grained access control by centralizing secrets and overlaying access control policies, allowing for precise control over who can access which credentials and providing a clear audit trail of actions taken.

  • What is the concept of dynamic secrets in Vault?

    -Dynamic secrets in Vault refer to the practice of providing short-lived, ephemeral credentials to applications instead of long-lived credentials. This limits the potential damage if a secret is leaked, as the leaked credential is only valid for a limited time and can be easily revoked and replaced.

  • How does Vault help with the management of encryption keys?

    -Vault offers an 'encrypt as a service' capability, which allows it to manage encryption keys and perform cryptographic operations on behalf of applications. This ensures that cryptography is correctly implemented and that key management is offloaded from developers to Vault, simplifying the process and reducing the risk of errors.

  • What are the three major challenges that Vault is designed to help developers with?

    -The three major challenges are: 1) Moving credentials out of plaintext and into a centrally managed system with tight access control and clear visibility; 2) Protecting against applications that aren't trusted to keep secrets by using dynamic secrets; 3) Helping applications protect their own data at rest through key management and high-level cryptographic offload.

  • How does Vault's architecture contribute to its flexibility?

    -Vault's architecture is highly pluggable, with different extension points such as authentication backends, auditing backends, and secret backends. This allows Vault to integrate with a variety of identity providers, audit log systems, and storage systems, and to manage a wide range of secrets through the addition of new secret backends.

  • What are some examples of secret backends in Vault?

    -Examples of secret backends in Vault include key-value stores for static credentials, database plugins for dynamic management of database credentials, RabbitMQ for message queue credentialing, AWS for managing cloud resource access, PKI for certificate management, and SSH for brokering access to SSH servers.

  • How does Vault ensure high availability in a deployment?

    -Vault ensures high availability by running multiple instances of the service, using a shared backend storage system, and performing leader election to designate an active leader that processes client requests. If the current leader fails, a new leader is automatically promoted to take over operations.

  • What type of API does Vault typically expose for client interactions?

    -Vault typically exposes a RESTful JSON API over HTTP, making it easy to integrate with applications and allowing clients to interact with it using standard HTTP methods.

  • Why is it important for Vault to encrypt secrets both at rest and in transit?

    -Encrypting secrets both at rest and in transit ensures that even if someone gains access to the storage location or intercepts the communication, the secrets remain secure and unreadable without the decryption keys. This is a fundamental aspect of Vault's security model.

Outlines

00:00

πŸ” Introduction to Secret Management and Vault

The paragraph introduces the concept of secret management, emphasizing the importance of managing credentials that grant access to systems. It explains that secrets can include usernames, passwords, database credentials, API tokens, and TLS certificates. The issue of secret sprawl is highlighted, where secrets are scattered across infrastructure, often in plaintext, leading to security risks. The introduction of Vault is presented as a solution to centralize and encrypt secrets, providing fine-grained access control and audit trails, thus improving the management and security of sensitive information.

05:01

πŸ”„ Challenges with Secret Management and Dynamic Secrets

This paragraph discusses the challenges of managing secrets, particularly the tendency of applications to leak credentials. It introduces Vault's second-level capability of dynamic secrets, which are short-lived and ephemeral, reducing the impact of a leak by limiting the lifespan of credentials. The benefits of dynamic secrets include creating a moving target for attackers, unique credentials per client, and improved revocation capabilities. Additionally, the paragraph addresses the challenge of protecting application data at rest and introduces Vault's encrypt-as-a-service feature, which offloads cryptography implementation and key management from developers to Vault, ensuring secure and correct implementation.

10:01

πŸ› οΈ Vault's High-Level Architecture and Pluggability

The paragraph delves into Vault's architecture, highlighting its pluggability and the ability to fit into various environments. It outlines the core components of Vault, including authentication backends for client identification, auditing backends for tracking activities, and storage backends for durable and available data storage. The paragraph also explains the secret backends that allow for the management of different types of secrets, either static or dynamic, and how Vault's architecture enables the secure and efficient handling of credentials and encryption keys through its RESTful JSON API.

15:03

🌐 Understanding Vault's Deployment and Operation

The final paragraph provides an overview of how Vault operates in a deployment context, emphasizing its high availability through multiple instances and leader election. It explains how Vault functions as a shared network service accessible via a RESTful JSON API, allowing clients to interact with it seamlessly. The paragraph concludes by encouraging further exploration of Vault's resources for a deeper understanding of its capabilities and applications.

Mindmap

Keywords

πŸ’‘Secret Management

Secret Management refers to the process of securely handling and storing sensitive information or credentials that grant access to systems. In the context of the video, it is about addressing the challenges of securely managing credentials such as usernames, passwords, API tokens, and TLS certificates to prevent unauthorized access and maintain system security.

πŸ’‘Vault

Vault is a tool designed to solve the secret management problem by providing a centralized, secure, and auditable way to store and manage sensitive credentials. It encrypts secrets both at rest and in transit, ensuring that only authorized clients can access them.

πŸ’‘Secret Sprawl

Secret Sprawl is the uncontrolled distribution of sensitive information across multiple systems, often in plain text, leading to security risks. It makes it difficult to manage, audit, and rotate credentials, increasing the potential for unauthorized access and data breaches.

πŸ’‘Encryption

Encryption is the process of converting plain text into a coded format to prevent unauthorized access. In the context of the video, Vault uses encryption to protect secrets both when they are stored (at rest) and when they are being transmitted (in transit).

πŸ’‘Access Control

Access control refers to the mechanisms and policies that regulate who or what can view or use resources in a computing environment. In the video, Vault allows for fine-grained access control, enabling the definition of specific permissions for different clients or users, thus enhancing security and reducing the risk of unauthorized access.

πŸ’‘Dynamic Secrets

Dynamic Secrets are temporary credentials that are created, used, and then revoked within a short period, reducing the risk associated with long-lived credentials. This approach ensures that even if a secret is compromised, its validity is limited, making it less valuable to an attacker.

πŸ’‘Audit Trail

An audit trail is a record of all actions taken by users or systems that can be used for review, analysis, or legal purposes. In the context of the video, Vault provides an audit trail that allows for visibility into who accessed which credentials, enhancing accountability and security monitoring.

πŸ’‘Pluggable Architecture

A pluggable architecture is a design approach that allows components or extensions to be added or removed easily without affecting the core functionality of the system. In the video, Vault's pluggable architecture enables the addition of various authentication backends, storage backends, and secret backends to adapt to different environments and use cases.

πŸ’‘Authentication Backends

Authentication Backends are systems or services that verify the identity of a user or an application trying to access a resource. In the context of the video, Vault supports multiple authentication backends, such as AWS, LDAP, Active Directory, and Kubernetes, to integrate with existing security frameworks and authenticate clients securely.

πŸ’‘Storage Backends

Storage Backends are systems responsible for the durable storage of data at rest. In Vault, storage backends ensure that secrets and other data are securely stored, typically in a highly available and fault-tolerant manner.

πŸ’‘Secret Backends

Secret Backends in Vault are components that handle the management of specific types of secrets, such as database credentials, message queue credentials, or TLS certificates. They enable Vault to provide dynamic secret capabilities and other secret management features.

Highlights

The introduction of Vault as a solution to the secret management problem.

Definition of a secret as any credentials that grant authentication or authorization to a system.

The issue of secret sprawl, where secrets are scattered across infrastructure and source code.

The importance of understanding who has access to secrets and the lack of audit trails in many systems.

The centralization of secrets as a solution to secret sprawl, with Vault promising encryption both at rest and in transit.

Vault's ability to overlay fine-grained access control, enhancing security and visibility.

The concept of dynamic secrets, providing short-lived and unique credentials to applications to reduce the risk of credential leakage.

The advantage of dynamic secrets in creating a moving target for attackers and facilitating pinpointing the source of a compromise.

Vault's role in better revocation management, allowing for the isolation of compromised credentials.

The challenge of applications storing data and the need for effective encryption key management.

Vault's encrypt-as-a-service feature, offloading the responsibility of cryptography from developers to the platform.

The high-level API provided by Vault for cryptographic operations, ensuring correct implementation and key management.

Vault's high pluggability, with multiple extension points for authentication, auditing, and storage backends.

The use of authentication backends to allow clients to authenticate from various systems.

Vault's architecture supporting multiple audit logs for comprehensive tracking of activities.

Storage backends responsible for durable and highly available storage of secrets.

Secret backends enabling dynamic secret capabilities and extending Vault's functionality for various use cases.

Vault's operation as a shared network service with a RESTful JSON API for easy integration with applications.

Transcripts

play00:09

i'm armand and today i want to spend

play00:11

some time talking about vault so when we

play00:15

talk about vault the problem we're

play00:16

really talking about solving is the

play00:18

secret management problem and so when we

play00:20

start talking about secret management

play00:22

the first question that naturally comes

play00:23

up is what is a secret so when we talk

play00:25

about secret management what we're

play00:27

really talking about is managing a set

play00:29

of different credentials right and so

play00:31

what we mean when we talk about these

play00:32

credentials is anything that might grant

play00:34

you authentication to a system or

play00:36

authorization to a system right so some

play00:39

examples of this might be usernames and

play00:42

passwords it might be things like

play00:45

database credentials it might be things

play00:48

like API tokens or it might be things

play00:52

like TLS certificates the point is any

play00:55

of these things we can use these to

play00:58

either login to a system and

play00:59

authenticate such as a username and

play01:01

password or we're using to prove our

play01:02

identity sup like a TLS certificate and

play01:05

so we're using it to authorize access

play01:07

potentially so all of these things fall

play01:09

in the realm of secrets and these are

play01:11

things they want to carefully manage we

play01:12

want to understand who has access to

play01:14

them we want to understand you know

play01:16

who's been using these things and in the

play01:19

case of most of these we want some story

play01:20

around how we can periodically rotate

play01:22

these and so when we look at the kind of

play01:24

state of the world of how these things

play01:25

get managed in practice what we see a

play01:28

secret sprawl right and what we mean by

play01:31

secret sprawl is that these end up

play01:33

everywhere they're in plain text inside

play01:35

of our source code so maybe it's

play01:37

hard-coded in a header what the user

play01:38

name and password it is it ends up

play01:40

inside of things like configuration

play01:42

management so again this is living in

play01:45

plain text and chef or puppet or ansible

play01:47

and so anyone can log in and see what

play01:48

these credentials are and ultimately all

play01:50

of this typically ends up living in a

play01:52

version control system like github or

play01:54

get lab or bitbucket and so these things

play01:57

end up sort of strewn about or sprawled

play01:59

all over our infrastructure and so what

play02:01

are the challenges with this world well

play02:03

we don't really know who has access to

play02:05

all of these things so we don't know

play02:07

does anyone in our organization with

play02:08

access to github can they log in and see

play02:10

the source code and thus see what our

play02:12

database credentials are right and even

play02:14

if they could do it we don't know if

play02:15

they have done it we have no audit trail

play02:17

that says just because I Arman could

play02:19

have seen that secret did he go on and

play02:21

so we really have no fine-grained

play02:23

ability to manage who has access or to

play02:25

even audit who's done what with it were

play02:27

skin how do we actually rotate any of

play02:29

these things so if we realize we do need

play02:31

to change our database credential

play02:32

there's been a compromise or we're doing

play02:34

a periodic rotation it's very very

play02:35

difficult if we're in a place where it's

play02:37

hard-coded in our source code or its

play02:39

Stern about in so many different systems

play02:40

that it's really difficult to really

play02:42

know how to effectively do this rotation

play02:44

and so this state of the world is what

play02:47

we refer to as secret sprawl and so one

play02:49

of our first goals and we started

play02:50

working on vault was to really look at

play02:52

this problem and say how can we improve

play02:54

it and so this is really where vault

play02:57

came from so vault really starts by

play02:59

looking at the secret sprawl problem and

play03:01

saying we can only solve it by

play03:03

centralizing right so instead of having

play03:05

things live everywhere we move all these

play03:08

secrets to a central location and vault

play03:10

promises that we're going to encrypt

play03:12

everything both at rest inside a vault

play03:15

as well as in transit between vault and

play03:19

any of the clients that want to access

play03:21

it right and so this gives us a few

play03:24

properties one unlike these systems

play03:26

where we're restoring the stuff in

play03:27

plaintext at least now if you could see

play03:29

where the secret is stored at rest it's

play03:31

encrypted

play03:32

so you don't get implicit access to just

play03:34

be able to see this secret the next

play03:36

thing is vault lets us overlay

play03:37

fine-grained access control on top of

play03:39

all this so instead of it being anyone

play03:42

in our organization who has access to

play03:43

github and can see the source code now

play03:45

we can go much more fine-grained and say

play03:46

you know the web server needs access to

play03:48

the database credential the API server

play03:50

needs the API tokens but everyone

play03:53

shouldn't have access to everything and

play03:55

then on top of this we have an audit

play03:57

trail so now we can actually see what

play04:00

credentials is a web server access what

play04:01

credentials did Arman access from the

play04:03

system and so we have much more

play04:05

visibility and control over how these

play04:07

things are all being managed this is

play04:10

sort of the level one challenge with

play04:12

vault is at least moving from a world of

play04:14

sprawl where things are everywhere to

play04:15

world of centrality where we have sort

play04:17

of strong guarantees that it's encrypted

play04:19

strong guarantees around who has access

play04:21

and strong visibility into this so this

play04:26

becomes our first level thing the next

play04:28

level challenge becomes realizing who

play04:30

we're giving these credentials to right

play04:31

so great we've store all these

play04:33

credentials safe

play04:34

in volt and now we're gonna thread these

play04:35

out and provide it to an application the

play04:38

challenges applications do a terrible

play04:40

job keeping secrets inevitably the

play04:42

application will log its credentials out

play04:44

to a logging system so I might write it

play04:47

out to standard out this gets shipped

play04:49

off to Splunk and is now in a central

play04:50

log that anyone can see it shows up in

play04:53

any sort of a diagnostic output so maybe

play04:56

our application has an exception and it

play04:57

shows the username and password and the

play04:59

trace back or inside of an error report

play05:00

it might be shipping it out to external

play05:02

monitoring systems when there is an

play05:05

error and so in general what we find is

play05:07

applications do a poor job keeping

play05:09

things secret so even if we do a great

play05:11

job centralizing it and strongly

play05:13

controlling it and encrypting it on the

play05:14

way to the application the app isn't

play05:17

trusted so one of the second-level

play05:19

capabilities of all introduces is what

play05:21

we call dynamic secrets and the idea

play05:24

behind a dynamic secret is instead of

play05:26

providing a long-lived credential to the

play05:28

application which it inevitably leaks we

play05:31

provide short-lived ephemeral

play05:33

credentials so these things are

play05:34

dynamically created but they're

play05:36

ephemeral so we might only give a

play05:38

credential to an application that's

play05:40

valid for say you know 30 days and the

play05:43

value of this is a few fold now even if

play05:46

the application leaks this credential

play05:48

out it's only valid for a bounded period

play05:50

of time so it might write it to a

play05:51

logging system and that becomes visible

play05:53

but we create a moving target for an

play05:55

attacker by constantly revoking and

play05:56

issuing new certificates the other thing

play05:59

that's valuable is now each credential

play06:01

is unique to each client so previously

play06:03

if I had 50 web servers all of them

play06:05

would come in and read a static database

play06:07

credential and so this means if there's

play06:09

a compromise and that database

play06:10

credential gets out it's very hard to

play06:12

pinpoint where the point of compromise

play06:14

was there's 50 servers they're all

play06:15

sharing the exact same credential versus

play06:18

in a dynamic secret world each of those

play06:19

50 web servers had a unique credential

play06:21

so you know very specifically web

play06:23

machine 42 was the point of compromise

play06:25

right the last thing that this lets us

play06:28

do is have a much better revocation

play06:30

story so now if we know web machine 42

play06:33

was our point of compromise we can

play06:34

revoke the password username and

play06:36

password for just web machine 42 and

play06:38

isolate that leak but if all 50 machines

play06:41

were sharing the same username password

play06:43

the moment we try and revoke it would

play06:44

cause the entire service to have an out

play06:46

right so the blast radius of a

play06:48

revocation is much larger when you have

play06:50

a shared secret versus the dynamic

play06:52

secret the third challenge we found was

play06:56

that applications are often storing data

play06:58

ultimately and so the challenge becomes

play07:02

right how do the applications protect

play07:04

their own data at rest because we're not

play07:07

going to be able to store all sort you

play07:08

know all information with involved well

play07:10

is meant just to manage secrets not

play07:12

anything that might be confidential so

play07:14

what we often see is that one is vault

play07:16

as being used as a centralized sort of

play07:18

secret management store people are

play07:19

storing encryption keys so we might put

play07:22

an encryption key inside a vault and

play07:25

then distribute that key back out to the

play07:27

application the application is doing

play07:29

cryptography to protect data at rest

play07:30

what we find though is applications

play07:33

generally don't implement cryptography

play07:35

correctly there's lots of subtle nuances

play07:36

and it's easy to get wrong and with

play07:39

these kind of you know mistakes often

play07:40

times it compromises the whole

play07:42

cryptography when those mistakes are

play07:44

made and so one of the challenges we

play07:46

often look at is how do we get away from

play07:48

ultros storing an encryption key and

play07:50

handing it to the application and

play07:51

assuming the app will do cryptography

play07:53

right so this has evolved into a

play07:55

capability that vault calls encrypt as a

play07:57

service and the idea here is instead of

play08:02

expecting that we're just going to

play08:03

deliver a key to a developer and the

play08:05

developer implements cryptography

play08:06

correctly volt will do a few things one

play08:09

is it will let you create a set of named

play08:11

keys so I might create a key that I call

play08:13

you know credit card information and a

play08:15

separate one I call a social security

play08:16

number and one for PII and these are

play08:19

just names I'm gonna just name this key

play08:21

and I'm not going to actually give this

play08:23

value out but then what we expose is a

play08:26

set of high-level API is to do

play08:30

cryptography so these API so be kind of

play08:32

the classic operations you expect right

play08:34

things like encrypt or decrypt or sign

play08:37

or verify so now as a developer what I'm

play08:41

really doing is calling volt with an API

play08:44

and saying you know I want to do an H

play08:46

Mac using my credit card key and some

play08:50

piece of data right and what volt is

play08:54

shielding is the implementation is being

play08:56

provided by volt so we don't have to

play08:58

trust that the developers implement at

play08:59

these hilum

play09:00

operations correctly and the key

play09:02

management is also being provided by

play09:03

volt the developer never actually sees

play09:05

the underlying key this lets us do a few

play09:08

things one it ensures that the

play09:10

cryptography is correctly implemented

play09:11

because we're using a vetted

play09:13

implementation by volt this

play09:14

implementation is vetted both by us by

play09:16

the open source community and by

play09:18

external auditors that we use it also

play09:20

lets us offload key management so if we

play09:22

think her prog rafi is hard key

play09:23

management's even harder and so in

play09:25

practice when you ask how many

play09:26

applications properly implement key

play09:28

versioning key rotation key

play09:30

decommissioning and the full lifecycle

play09:32

of key management the answer is very few

play09:34

because it's challenging but by

play09:35

offloading this to vault we can actually

play09:37

use high-level api's to do all of this

play09:39

so we get the full key lifecycle as well

play09:42

provided by vault and so in practice

play09:45

these end up being the three major

play09:47

challenges that we're trying to help

play09:48

developers with right how do we move

play09:50

these credentials out of plain text and

play09:52

sprawled across many different systems

play09:53

into a scenario where they're centrally

play09:55

managed with tight access control and

play09:57

clear visibility - then how do we go

play09:59

even further and protect against

play10:01

applications that aren't necessarily to

play10:03

be trusted in keeping secrets and we do

play10:05

this by being ephemeral so we create

play10:07

this moving target where what we're

play10:08

really managing is that the web server

play10:10

should have access to the database and

play10:12

that credential that enables it is

play10:14

dynamic is a dynamic one instead of

play10:16

static and then lastly how do we go

play10:18

further in helping the application

play10:19

protect its own data at rest and that's

play10:22

done through a series of key management

play10:24

and high level cryptographic offload so

play10:26

these three are kind of the core

play10:27

principles of vault so now maybe we'll

play10:30

zoom in quickly and talk a bit about

play10:32

high level architecture of how does this

play10:34

actually get implemented so when we talk

play10:37

about vault architecture there's a few

play10:39

important things to realize one is the

play10:41

vault is highly pluggable it has many

play10:43

different plug-in mechanisms so when we

play10:45

talk about vault it has the central core

play10:48

which has many responsibilities

play10:50

including sort of the lifecycle manager

play10:52

and ensuring requests are processed

play10:53

correctly and then there's many

play10:55

different extension points that allow us

play10:56

to fit it into our environment so the

play10:59

first one that's extremely important is

play11:00

the authentication backends these are

play11:03

what allow vault to allow clients to

play11:05

authenticate from different systems so

play11:06

for example if we're booting an ec2 VM

play11:09

this ec2 VM might Ascenta gate

play11:12

using our AWS authentication plugin this

play11:16

plugin allows us to tie back into

play11:17

Amazon's notion of identity to prove

play11:20

that the color is for example a web

play11:21

server but if we're have a human user

play11:23

they might be coming in and using

play11:25

something like LDAP or Active Directory

play11:27

to prove their identity if we're using a

play11:31

high level platform maybe something like

play11:33

kubernetes we might be using our

play11:35

kubernetes authentication provider and

play11:37

the goal of these authentication

play11:39

providers is to take some system we

play11:40

trust whether it's kubernetes LDAP or

play11:43

AWS and use this to provide application

play11:46

or human identity at the end of the day

play11:48

that's what we're getting out of this is

play11:50

a notion of the identity of the caller

play11:54

this is great and then we use that to

play11:57

connect to an auditing back-end which

play12:00

allows us to connect and stream out

play12:01

request response auditing to an external

play12:04

system that gives us a trail of who's

play12:07

done what so this might be you know

play12:08

Splunk as an example where we're going

play12:11

to send all of our different audit logs

play12:12

vult will allow us to have multiple

play12:14

different audit logs so we can also sent

play12:15

a Splunk as well as a system like syslog

play12:18

as an example the next level challenge

play12:21

is where does vault actually store its

play12:23

own data at rest right so if we're gonna

play12:25

read and write secrets to vault it needs

play12:27

to be able to store these things

play12:28

somewhere and so these are what we call

play12:29

storage backends so storage back ends

play12:31

are responsible for storing data at rest

play12:33

so this can be really a couple of

play12:36

different things it could be a standard

play12:37

our DBMS so you know my sequel Postgres

play12:41

it could be a system like console it

play12:43

could be a cloud managed database like

play12:45

google spanner but the goal of these

play12:48

back-end systems is to provide durable

play12:50

storage in a way that's highly available

play12:52

so we can tolerate the loss of one of

play12:54

these back-end systems the last bit is

play12:56

how does console actually I'm sorry

play12:58

vault provide access to different

play13:00

secrets these are the secret backends

play13:04

themselves and so these come in a few

play13:05

different forms so the biggest use of

play13:08

these is to enable the dynamic secret

play13:10

capability we talked about before so one

play13:12

form of secret back-end is a simple one

play13:15

it's just key value so I might just

play13:16

store a static username and password in

play13:18

there and I'm giving it a username and a

play13:20

password and these things are static and

play13:22

this is just a key value store that's

play13:24

encrypted at rest

play13:25

however as we get more sophisticated we

play13:28

might want to use the dynamic secret

play13:29

capability we talked about and so that

play13:32

is where these different plugins are

play13:33

coming in so we have different database

play13:35

plugins it's a database plugin will

play13:37

allow us to dynamically manage my sequel

play13:40

and Postgres and Oracle and etc

play13:42

credentials we have things like RabbitMQ

play13:45

so maybe we're doing dynamic

play13:47

credentialing for our message queues but

play13:51

this kind of goes on you can even apply

play13:52

the same principle to something like AWS

play13:54

we might have applications that need to

play13:56

read and write from s3 but we don't want

play13:58

to give them long-lived access to iam so

play14:01

instead we define a role in our AWS back

play14:03

in and we'll go and dynamically generate

play14:05

short-lived credentials as needed so

play14:08

this extends that sort of dynamic secret

play14:10

paradigm so this is an extension point

play14:13

that allows both to apply this same

play14:14

principle to many different things one

play14:16

common use of this is PKI so in practice

play14:20

certificate management tends to be a

play14:21

nightmare and what we often see is very

play14:23

long live certificates maybe five to ten

play14:25

year lived certificates because we don't

play14:27

want to go through the process of

play14:28

generating them versus with a vault we

play14:31

can define them and programmatically

play14:32

generate it so in practice people use

play14:34

very short live certificates maybe a

play14:35

shortest 72 24 hours and this way you're

play14:39

constantly moving and creating a movie

play14:41

target this list sort of goes on and

play14:44

includes things like SSH as an example

play14:46

so we can broker access to SSH as well

play14:48

so you don't have a single PEM to rule

play14:50

them all across a large state of

play14:52

machines so at its core this is what

play14:54

makes fault so flexible right it allows

play14:57

fault to manage clients that are

play14:58

authenticating against a different set

play15:00

of identity providers we can audit

play15:03

against a variety of different trusted

play15:05

sources of log management we can store

play15:08

data in almost any durable system and

play15:10

then we can extend the surface area of

play15:12

what types of Secrets can be either

play15:14

statically or dynamically managed by

play15:16

adding new secret backends so this

play15:18

becomes a vault in a single instance

play15:20

nutshell so as we talk about running a

play15:22

vault instance each instance of it is

play15:24

one of these and then in a broader

play15:28

deployment what this will look like is

play15:30

we run multiple instances to provide

play15:33

high availability so at the highest

play15:35

level we'd have a shared back-end for

play15:37

example this might be

play15:38

console which internally is you know

play15:41

three different servers as an example

play15:43

providing us a che and then we will run

play15:45

multiple vaults in front and what fault

play15:48

does is he'll coordinate with the shared

play15:50

back-end to perform leader election so

play15:52

one of these might be elected our

play15:53

current leader and so as a client when

play15:56

we're making requests we're talking to

play15:58

the leader and even if we talk to sort

play16:00

of a non leader will be transparently

play16:01

forwarded to the active leader and so in

play16:03

this way if any particular node dies

play16:05

power loss process crashes you know

play16:08

maybe network connectivity as an issue

play16:10

we will detect this detect and promote a

play16:13

new one to leader automatically and this

play16:15

instance takes over active operation and

play16:17

our other secondaries will begin to

play16:19

promote and so this is what volt looks

play16:21

like at a high level it operates as sort

play16:23

of a shared network service and we're

play16:25

talking to it just as an API client over

play16:27

the network

play16:28

so what volt typically exposes it's a

play16:30

restful JSON API so it's JSON over HTTP

play16:35

making it relatively easy to actually

play16:37

integrate with our applications I hope

play16:40

this was useful as a high-level

play16:42

introduction to volt and please check

play16:43

out our other resources to learn more

play16:45

thank you

Rate This
β˜…
β˜…
β˜…
β˜…
β˜…

5.0 / 5 (0 votes)

Related Tags
Secret ManagementSecurity EnhancementCredential CentralizationDynamic SecretsApplication SecurityData ProtectionSystem AuthenticationAccess ControlCryptographyKey Management