TalkingTrust with Thales and HashiCorp – DevSecOps

TalkingTrust Series - HashiCorp - DevSecOps

 

00:10 Good morning everyone

00:11 and welcome to this webinar hosted by

00:13 Thales and HashiCorp.

00:15 My name is Chintan Gosalia and I'm a

00:17 Senior Solutions Engineer

00:19 at HashiCorp. Previously I also worked for Thales,

00:23 so I'm super excited to be working on

00:25 this webinar with the team there.

00:28 I agree. My name is David Madden and I’m

00:30 thrilled to be here with Chintan today to talk about

00:33 applying roots of trust for devops secrets in Vault

00:37 using an HSM. Today in this webinar we're

00:40 going to plan and discuss a number of things,

00:43 including a very interesting challenge that we're

00:46 seeing out there in the world with

00:47 secrets sprawl that

00:49 a lot of our large organizations are running into. 

00:52 We're also going to talk about how

00:54 organizations can address this with HashiCorp Vault

00:57 Secrets Management, and also how they can

01:00 leverage an HSM as a root of trust to

01:01 protect these secrets stored in the Vault,

01:04 as well as ensuring automation for devops.

01:07 According to our friends at IDC, one of the things

01:10 organizations see as they digitally transform

01:14 is the shift from a service provider

01:16 approach to a core part of the digital

01:18 value chain creation,

01:19 making devops what Hashi and Thales do a

01:22 core asset of any business in the digital economy. 

01:25 So we're going to talk about this, talk about that impact

01:28 to really every organization that's digitally transformed.

01:31 So let's get started on this TalkingTrust

01:33 with Thales and HashiCorp,

01:35 and I think the first place maybe we do

01:37 that Chintan is the is around

01:39 secret sprawl, which is on a lot of

01:41 people's minds today. Can you

01:42 describe it in a little more detail

01:44 what's causing secret sprawl?

01:48 That's a great question David. We all know that to thrive

01:52 in today's digital economy every organization

01:55 is heavily investing into digital transformation.

02:00 The goal of this transformation is to accelerate building

02:03 and delivery of applications to its customers,

02:07 and the two critical components to

02:09 achieve this acceleration are:

02:11 number one transition to the modern data center

02:15 that provides on-demand resources; and number two

02:18 adoption of agile and automated devops workflows.

02:23 Now this transition has created a unique

02:26 challenge of secret sprawl.

02:28 For example as a team dynamically scales

02:31 up the number of app servers

02:33 due to increased demand, these newly

02:36 provisioned app servers

02:37 need username and password to connect to

02:40 the database servers.

02:42 A Jenkins server may need to inject a GitHub API key

02:46 in its Ci CD pipeline, or they may also have micro services

02:50 that need tokens and certificates to

02:53 securely connect and communicate with each other.

02:57 The outcome is a lot more sensitive

03:00 secrets to manage

03:01 than they ever had, due to the automated

03:04 dynamic workflows.

03:09 In a recent survey 81 person organizations confirm

03:13 that they have experienced secret sprawl,

03:16 and worry about leakage or

03:18 compromise of secrets that can lead to a breach.

03:22 Traditionally the organizations relied

03:24 on storing the secrets in plain text,

03:27 either in config files, application code,

03:30 or even providing secrets manually by human operators.

03:35 This was an acceptable risk in a static

03:38 and high trust network

03:40 in the four walls of a data center,

03:43 but the infrastructure in public clouds

03:45 are no longer owned by

03:47 application owners and without any defined boundaries.

03:51 Networks are considered low trust or zero trust,

03:55 so call these secrets in plain text in

03:57 some files or code.

04:00 What is required is a shift in our

04:02 secret management approach.

04:04 A solution that securely stores secrets,

04:07 and relies on service based identity

04:10 to deliver them to applications in an automated manner.

04:14 Right. Thank you Chintan. So now that we

04:18 understand why these customers are looking at secrets

04:20 and using them in so many different ways,

04:23 enabling them to really achieve

04:25 the benefits of digital transformation automation

04:28 and cloud native, now I think we should probably

04:31 discuss more about how they should best

04:33 approach implementing this

04:35 in a secure and of course a scalable way.

04:38 Can you share some details about how

04:40 Hashi’s approaching this?

04:42 Yeah another great question David. The

04:45 challenges we discussed

04:46 are why HashiCorp Vault has become a 

04:49 de facto standard

04:50 for secret management in a multi-cloud

04:53 environment with devops workflows.

04:56 Its success can be attributed to its

04:58 three core principles.

05:00 The first one is extensible architecture.

05:03 Vault supports a variety of secrets

05:06 through its secrets engines.

05:08 For example, a PKI secrets engine can

05:11 dynamically generate digital certificates.

05:14 KV secrets engine can store any static secrets.

05:18 And MySQL secrets engine can dynamically

05:20 generate MySQL database credentials.

05:24 There is a secret engine available for

05:26 any well-known type of secret

05:28 and its workflow. This extensible and

05:31 pluggable architecture

05:33 allows Vault to provide a single pane of glass

05:37 to manage any secrets in any environment.

05:42 The second principle is its ability to secure

05:45 with any identity. Vault integrates with pretty much

05:49 all popular identity providers, for example

05:53 a client can authenticate with Vault using its

05:56 GitHub credentials when requesting a secret.

06:00 In a development environment, the same client can use

06:03 Okta or AD credentials when requesting a secret

06:07 from a corporate network, or use AWS IM credentials

06:12 for a secret in the AWS environment.

06:15 This allows Vault to provide secrets to any client

06:19 in any environment.

06:22 The third principle is its API-first approach.

06:26 Every operation in the world is

06:29 available through a CLI

06:31 and API, and hence it seamlessly integrates

06:35 with any existing human or devops workflow.

06:40 Nice. Now I see why organizations are adopting Vault

06:43 to effectively manage their secret

06:45 sprawl. You know, leveraging these capabilities.

06:48 But doesn't that now make Vault a target

06:51 as it now stores the crown jewels to the

06:53 organization's devops infrastructure?

06:56 Can you tell us how Vault can help address this risk?

07:00 Yeah, it definitely does, and to address this risk

07:03 Vault encrypts all its data in storage

07:06 with an encryption key.

07:09 This encryption key is then encrypted with a master key,

07:13 which is then protected by another key

07:15 known as an unseal key. This unseal key

07:19 can be referred to as the root of trust

07:21 for Vault, as it allows the Vault to

07:24 unlock all secrets stored inside it. This is why

07:28 it is very critical to protect

07:30 this unseal key. Right, so I guess now the

07:33 question in the minds of

07:35 of our listeners is how does Vault

07:37 protect this unsealed key. 

07:40 Yeah, in its default configuration wall protects

07:44 the unseal key using Shamir’s secret sharing. 

07:48 The unseal key is split into N different key shares.

07:53 Each key share is then provided to a

07:55 separate key custodian, so there are N key custodians

08:00 each knowing a part of the key instead

08:02 of a single person knowing the entire key value.

08:07 A certain threshold of shares also known as K

08:11 is required to reconstruct the unseal key.

08:14 The default value of N is five and K is three,

08:18 so at least three out of five key

08:20 custodians are required

08:22 to reconstruct the unseal key. 

08:25 Whenever a Vault is started, K number of

08:28 key custodians

08:30 must provide their key shares to

08:32 recreate the unseal key.

08:34 They will decrypt the master key which

08:36 will allow Vault to decrypt secrets,

08:39 and fulfill any requests coming from authorized clients.

08:44 This is a secure process as no single key custodian

08:48 knows the unseal key, but there are a

08:51 couple of considerations to using Shamir’s 

08:53 secret sharing as the root of trust for Vault. 

08:58 First, it makes starting or restarting

09:01 Vault a manual process.

09:04 Vault may need to be restarted at odd

09:06 hours due to outages

09:08 or planned maintenance activities, and using

09:11 Shamir’s secret sharing as a root of trust will require

09:14 a human intervention during such events.

09:19 Second, the unseal key is generated using

09:22 Vaults software crypto libraries.

09:25 Many organizations have strict security requirements

09:29 to leverage FIPS 140-2 Level 2

09:33 or Level 3 validated hardware devices

09:36 to generate and manage such critical encryption keys.

09:40 Ah, this is really good to know, thanks

09:41 for sharing that. And as you have mentioned,

09:44 many organizations require an automated unseal process

09:47 and a hardware-based root of trust can

09:49 help meet their compliance requirements as well. 

09:52 And this is where Thales and HashiCorp

09:55 work together to provide an enhanced

09:57 HSM-based root of trust. Can you tell us

09:59 a little bit more about how this

10:01 integration works? Yes, the organizations

10:04 can leverage Thales Luna HSMs as the root of trust

10:08 instead of Shamir's secret sharing.

10:11 In this configuration the responsibility

10:14 of securing the unsealed key

10:16 is delegated from users to a highly secure

10:20 and trusted Thales Luna HSM. 

10:24 The unseal key here is generated and stored

10:27 only within the secure boundaries of a Luna HSM.

10:31 At startup, Vault will connect to a Luna HSM

10:35 via PKCS#11 API, and ask it to decrypt the master key.

10:42 As this process doesn't require any human intervention,

10:46 it is also referred to as automated unseal for Vault. 

10:51 The unseal key also never leaves HSM,

10:55 and hence not subject to unauthorized access

10:58 or leakage due to a human error.

11:04 Now let us review some of the benefits of leveraging

11:08 Thales Luna HSM as the root of trust

11:11 versus Shamir’s secret sharing.

11:14 The first benefit as we discussed is

11:16 automated unsealing,

11:19 it also improves the Vault security posture

11:22 as it eliminates any human errors around

11:25 securely storing and managing Vault unseal keys.

11:30 Second - Luna HSM is a FIPS 140-2

11:34 Level 3 and Common Criteria certified device,

11:38 and meets the most stringent security standards

11:41 for generation and management of encryption keys.

11:45 This enhances the root of trust security for Vault,

11:49 and all the secrets stores inside it.

11:53 With Luna HSM as the root of trust, 

11:56 Vault can also supplement

11:58 its system entropy with entropy from

12:01 Thales Luna HSM.

12:03 This can be quite critical for organizations

12:07 where alignment with cryptographic regulations like

12:10 NIST SP 800-90B is required,

12:14 or augmented entropy from hardware to random number

12:18 generators are desirable.

12:22 We typically see this as a requirement

12:24 for many of our Government

12:26 or Financial Services customers.

12:30 Vault can also leverage seal wrapping functionality

12:34 from Luna HSM, where it will store

12:37 its critical security parameters in a manner

12:41 that is compliant with key storage and

12:43 key transit requirements.

12:46 So in a nutshell, Luna HSM based root of trust

12:50 allows an organization to gain better security posture for

12:55 secrets stored in the Vault, while

12:57 benefiting from a highly operate

12:59 automated operational workflow.

13:04 Thank you for walking through this with us Chintan. 

13:07 So let me see if I can summarize. 

13:09 Typically, as we know,

13:10 security hinders automation and scale

13:13 and so this has been avoided

13:15 really at all costs until required by developers.

13:18 Additionally we're seeing the need for open source

13:22 APIs, CLI, and a broad ecosystem to ensure

13:25 a strong digital innovation for enterprises.

13:28 and so these things have been challenged

13:30 in the past, and now with the combination of Hashi Vault

13:33 and the Thales Luna HSMs, we have a strong

13:35 partnership that really empowers organizations

13:38 to meet their automation security and

13:40 compliance requirements such as FedRAMP, GDPR, 

13:45 PCI-DSS, digital signatures, code signing

13:48 and data encryption. And together we

13:51 enable the vision of devops in a secure

13:52 and efficient manner,

13:54 with the foundation of digital trust. And

13:56 to put this all in the context of the global pandemic,

13:59 IDC have found that teams practicing accelerated

14:04 application delivery and devops were in the position

14:08 to use software innovation and agility impact or

14:11 response to the crisis. They were

14:14 able to better roll out new releases in

14:15 a much shorter time,

14:16 and help drive the shift to a digital business.

14:20 So, we hope you're staying safe and

14:21 leveraging Hashi and Thales to support

14:23 your business plans in 2021

14:25 with our combined foundation of digital trust. 

14:29 Okay, so with this we reached the end of

14:32 our talk. I hope you found this helpful

14:34 and if you have any questions please

14:36 feel free to reach out to the Hashi

14:38 team at hello@HashiCorp.com, or the Thales

14:41 team at cpl.thalessgroup.com.

14:44 You can also feel free to send Chintan or I emails,

14:48 and we'll be happy to respond and follow

14:50 up. Thanks again for your time

14:52 Chintan, and I hope people have enjoyed

14:55 this. Have a great rest of the day.

14:56 Thank you David.