Duration 42:27
16+
Play
Video

Securing Kubernetes Secrets (Cloud Next '19)

Alexandr Tcherniakhovski
ДолжностьSecurity Software Engineer at Google
+ 1 speaker
  • Video
  • Table of contents
  • Video
Google Cloud Next 2019
April 9, 2019, San Francisco, United States
Google Cloud Next 2019
Request Q&A
Video
Securing Kubernetes Secrets (Cloud Next '19)
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
11.23 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Alexandr Tcherniakhovski
ДолжностьSecurity Software Engineer at Google
Seth Vargo
Senior Staff Engineer at Google

Alex is a Security Engineer at Google, working on Kubernetes Engine security. Previously, he worked on insider risk reduction. Before Google, Alex worked at Microsoft in security. He was a nationally ranked (Russian) tennis player in his teenage years.

View the profile

Seth Vargo is a Developer Advocate at Google. Previously he worked at HashiCorp, Chef Software, CustomInk, and a few Pittsburgh-based startups. He is the author of Learning Chef and is passionate about reducing inequality in technology. When he is not writing, working on open source, teaching, or speaking at conferences, Seth enjoys spending time with his friends and advising non-profits.

View the profile

About the talk

Secrets are a key pillar of Kubernetes’ security model, used internally (e.g. service accounts) and by users (e.g. API keys), but did you know they are stored in plaintext? That’s right, by default all Kubernetes secrets are base64 encoded and stored as plaintext in etcd. Anyone with access to the etcd cluster has access to all your Kubernetes secrets. Thankfully there are better ways. This lecture provides an overview of different techniques for more securely managing secrets in Kubernetes, including secrets encryption, KMS plugins, and tools like HashiCorp Vault. Attendees will learn the trade-offs of each approach to make better decisions on how to secure their Kubernetes clusters.

Share

Alright. Hello, everyone. Perfect. How's everyone doing this afternoon? Great, welcome to hybrid 200 securing kubernetes Secrets. My name is Seth. I'm a developer Advocate. I work on the developer relations team here at Google Google working on Google keeper need Ascension security team. He's going to come back in a little bit and show us some really cool live demos who's excited. The rest of you don't like live demos. Great. So in order to set some common ground, I know some of you were probably Security Professionals this

might seem a little bit repetitive, but I want to make sure that everyone is on the same page. So I want to start by talking and answering a very simple question. What is a secret? Purpose of this talk a secret is a credential a configuration at API key or some other piece of information that is required for an application either Advil time or run time. So some examples here might be like a database username and password or sensitive information that the application needs to run. And

that begs the next question which is why do we care? Why should we just not use social media as our secrets management tool? Why don't you start your secrets and publicly available tweets are an attractive Target for attackers. Secrets Austin protect sensitive information like personally identifiable information credit card number Social Security numbers passport numbers. They protect access to business data business intelligence data Lake analytics and reports they could damage your business or give your competitors an advantage. But then you couple that with how

easily credentials are leaked if we look at any of the recent security incidents we've seen, you know, access Keys leaked in a public in a repository because of a small mistake from a developer. We've seen yo improperly secured access to a dashboard or an interface allowing privilege escalation. It's very easy for us to leave these credentials and expose Secrets unintentionally. 7/3 Most secret actually have more permission than they need particularly when were talking about I am credentials or identity and access management

credentials. And that's because when you're a large startup, it's just much easier to give everyone root access because I I don't know what they're going to need in a week or two where I don't have to go through that. I need to move quickly and then oftentimes security as an afterthought. So when you combine these three things you have something that access is customer data or business data that's easily leaked and has overly broad permissions. It's an attacker's like best playground. This is why we need to invest effort in protecting our secrets and there are four

key ways in which we protect Secrets today. The first is auditing. We verify all of the use and access of individual secrets in some type of centralized system. This allows us to apply anomaly detection or machine learning to find out whenever a secret is being access out of the norm. Second we use encryption. All of our data should be encrypted in transit with TLS and it rest with the most secure algorithm for your use case and your industry. Third we should be rotating both

secrets and encryption Keys regularly in addition to a regular schedule of rotation. We need a break glass procedure what happens if right now we leak or credential how quickly can we rotate that credential across our infrastructure right? Now we leaking API key how quickly can we revoke and replace that API key rotation which decreases our surface area for an attack and we need immediate rotation in the event of an emergency. And for isolation is Keith. We want to separate where secrets are stored from where secrets are accessed that way in a Tucker has to compromise

multiple systems and escalate privilege multiple times in order to gain access to that plane text information. For the purposes of this talk we're going to be focusing on that second component specifically encryption. Now that doesn't mean that the other three are less important, but I only have 40 minutes. So we're going to focus on encryption. There are multiple layers of encryption you might have things like encrypted file systems, like filevault self-encrypting hard drives Etc. But you might also have same machine leveling corruption or service level encryption or apple

encryption layers of encryption for your data. No on Google Cloud, all of your data is encrypted at Rest by default. No configuration necessary, but you may want to apply additional layers of encryption to your data. Specifically you may want to leverage application layer encryption application layer encryption is applied at one of the earliest possible stages of the day does lifecycle secrets are encrypted before they leave your application or service with keys or a encryption tokens that only your application notes only your

application or only the critical components of your system. See the plaintext value. This enables very granular protection of data, you can use a different encryption key for each piece of customer data. That way if an attacker is able to brute-force that encryption key or the decryption key that same key will not work for another piece of customer data. And third this protects the data as it moves throughout the system. So if I have a hard drive in that hard drive is encrypted if I am out of the hard-driving decrypted somewhere, if an attacker as access on hard drive

access to all of the plain text Ada now go by leveraging application layer encryption my secret theater throughout the system. It remains encrypted regardless of the underlying storage mechanism, whether that's a memory a hard disk or a thumb drive. In the context of kubernetes application-layer encryption means that the kubernetes API server is responsible for performing the crypto operations. So in addition to your your application your pod your service, the curb is API server also has privilege to see those plain text secrets. And we advocate for defense-in-depth again use

multiple layers of encryption use application layer encryption combined with operating system encryption things like secure Boot and hard drive encryption. But always talk about kubernetes. The kubernetes default installation is not encrypted by default. So today if you were to download the open-source distribution of kubernetes and start up a kubernetes cluster regardless of cloud provider regardless and infrastructure. The underlying secrets are not encrypted. That means that anyone who has access to STD

or a backup of STD has access to all of your plane texting all of your secrets in plain text. Let me show you what that looks like. Here. I have a credit card or a piece of data. I'm using this image to show that this is a secret. As a user or as an application, I give that piece of secret data to the kubernetes API server when I say could cuddle create secret or the associated API call. The Carbonite is API server, then Bay 64 and codes that data and rice at SED a

joke. So the absolute the secret to the API server, push us out an STD in the plain text. That means that if an attacker has access to the master node an online at CD server or a backup of the STD database all of your secrets are available in plain text. Again, this is a default kubernetes installation regardless of cloud regardless of infrastructure the open-source distro out of the box. This is calling crashing. In Crafton is what happens when you confuse

encryption with encoding. And my goal here is like not to make fun of Canadians right covid-19 is an amazing product and they've made great strides to improve the overall security. So while this is the default setup, let's talk about just how easy it is to extract secrets and then I'll talk about some of the improvements that communities has made to make it easier to secure your secrets. So if we could jump over to the street while you're ahead of me, perfect and I pull out my cheat sheet cuz cuz I'm only human All right. So what I have here is I'm using a mini

Cube, which is just a local kubernetes cluster and I have the base default installation of the latest version of kubernetes. And what I'm going to do here is I'm going to go into this folder and then I'm going to show you the command that I'm going to be running here. So I'm going to create a secret I'm going to use this default cluster that I've created and then I'm going to create a secret where I have a key value pair of the username and stuff Fargo and the password is very secure Secret in leet-speak. So let me go ahead and run this now so create

secret default. And I created that secret. So as I was showing before this is a default printer setup, which means it's toward an STD in plaintext. Let me show you what that looks like. If I access the default secret now, you'll notice that I get back some additional metadata here write a gift. I get back almost like a binary representation. There's some additional metadata in here, but most importantly right there. I've highlighted on the screen. That's the plain text password. That's the plain text user name all of that information that I supplied isn't playing texting at TD very easy

for an attacker to extract that information and escalate privilege in my system. So go ahead and jump back to the South Hill. Perfect. Now before we talked about some of the improvements that kubernetes has made let's talk about this concept called envelope encryption cuz it's very important cuz it's the underlying principle for how kubernetes Secrets encryption works. So envelope encryption is this idea of keys all the way down or Turtles all the way down. If you will there three pieces that were going to talk about here today. Again, we have our

data which is represented by this kind of credit card icon. We have a data encryption key or a deck represented by a red key and we have a key encryption key or a CAC represented by a Green Key. now when we want to encrypt data, we take the encryption key the red key and we encrypt the data. So we generate a key and we encrypt the data with that key and that produces encrypted data that is encrypted with are red key or data encryption key. Then we take our key encryption key and we

encrypt our data encryption key. So you'll notice here on the side. I have the credit card which is encrypted with the red key. And then I have the data encryption key, which is encrypted with the green key encryption key take both of those pieces of data and we put them together implementation details aside and we store them side-by-side in the in some people's storage back at file system database, whatever it might be. Any idea here is that each piece of data has a phone encryption key. We generate a new red key a new data encryption key for each piece of data. I'm about data is

maintained by is encrypted by a key encryption key, which has its own rotation schedule. When we want to reverse the process. The encrypted blob is separated into his two parts again implementation details. The key encryption key decrypts the data encryption key bits. Southern gives us the plain text Data encryption key encryption key and decrypt the remaining bits to give us back the original plain Text data. This is a very rudimentary and very quick overview of humble of encryption works. The key here is y'all are

not up for jokes, it's fine. The key here is that each new piece of data is encrypted with a new unique randomly-generated key and then we have a regular rotation schedule for our key encryption keys. So maybe that's monthly or weekly or quarterly depending on your threat model and your requirements. So there's some best practices for envelope encryption. We want to generate unique did encryption keys. So each piece of data is encrypted with its own high-entropy unique key. This allows us to do really cool things like so if we revoke

our key encryption key about top-level key. All the data encryption keys are now are recoverable by traditional Meats because they were encrypted with that key. Additionally we can rotate our key encryption keys on time intervals are in the event of an emergency while we rotate the Jenna and Christian Keyes each time. We modify the data this provides a very scalable way to do cryptographic operations. So now let's go back to kubernetes. So is 1.7 made its first attempt at solving this problem by introducing a new configuration option for encrypting

Secrets at rest before they enter at that looks like this. So this is what we call an encryption configuration and you'll notice inside this encryption configuration. I'm specifying an encryption provider in this example. It's an AES CBC provider and I'm giving it the basics before and coated encryption key. I take this encryption configuration as a yellow file. I load it onto my masternode or my crew is API server. I then start or restart my kubernetes API server bypassing in this encryption provider configuration option. I give it the path to that yellow file and

now we're good to go. Let me show you what this looks like in this new model. So going back to our original diagram. I have my credit card my secret data, I give it to the kubernetes API server is API server Dusty the plane texture, but the kubernetes API server delegates to that encryption provider configuration the encryption provider configuration encrypt the data before writing it to SGD. So we have random bytes of data in SED. So this means if an attacker had access to an online STD

database or a backup of the STD database, they would not be able to recover the plane text by traditional means But we're going to talk about access to the master be in a full disk backup of the master node, or the kubernetes API server that encryption configuration is on that same node in a file. It's in that yellow file that I showed earlier. So if an attacker was able to gain access to the VM they have access to the Keys then encrypted the data and you haven't actually improve

your security posture. Modeling perspective this actually wasn't any better, but it was a step in the right direction because now the community started thinking hey, we should actually be increasing our secrets and this is the way that we should do it. Is there a number of drawbacks with this approach the first you have to generate your own Keys? You need your own high-entropy source. You need to understand key algorithms. You need to understand. What is it? Like what are you going to use? You can use CBC Rica news Tuesday. I'm what type of tea do you want after you create those

keys? You don't need to manage them. You need to setup your own rotation schedule. You need to setup your own revocation schedule. You need to be responsible for making sure that they're always online. And each time you update those keys. You have to restart your kubernetes API server potentially causing downtime. Other said you have to rotate them on your own you have to update that can fig and if you're trying to get rid of old encryption Keys you actually after we encrypt all of your secrets. Another drawback is that many of you might be in organizations or regulatory

requirements where you're relying on hsms to achieve PCI or HIPAA compliance? And there's no way with the coronavirus 1.7 encryption provider configuration to leverage a Hardware security module. You can't leverage in HSM. So that was kind of a non-starter for some of those customers were depending on that. And most importantly as I already said the biggest drawback is that those encryption keys are stored in plain text in the file system. So from a threat modeling perspective, we haven't actually increase our security posturing by very much the keys are still available in plain

text and because the attacker could just get the keys and decrypt the data. So if I can an operation to get the plaintext data out of a CD So kubernetes 1.10 provides a much more secure solution using a new kind of Secrets provider KMS in this model kubernetes delegates encryption to a third-party can provider like Google Cloud cam Sr. Hashicorp Vault that looks like Again, it's the same encryption configuration. But instead of specifying the key is directly in this encryption configuration, which lives on disc we instead specify

the plug-in and the Unix socket where that plug-in resides. We load that up the same way that we did before but now there's a third party system in our flow. We have our secret data or a secret a to go to the API server the API server hits the encryption configuration the encryption configuration then makes a Unix socket call to in the case of Google Cloud API to encrypt decrypt this data. Google Cloud KMS then returns encrypted ciphertext, which is then stored

in a CD. Even if an attacker has access to the masternodes those encryption keys are maintained by an external system and attacker would have to compromise both the masternodes STD and the third party camera system in order to be able to decrypt those values offline. I got my song complicated. Right like that's a lot of things and that interaction with Unix socket send file permissions. That sounds difficult. But the community is already built a few of these for us. So there is an

open-source Google Cloud cam s plug-in that Alex actually worked on he's going to talk a little bit about it in a second. There's one for a sure there's one 480-volt. So the communities and the various special interest groups are working hard to make sure that your favorite Secrets Management Solutions at your favorite cannabis providers are supported as external cameras plug-ins for kubernetes. Now if you are on Google Cloud specifically we actually just wants to feature. It's a beta that does all of this for you. It is so easy that I actually

thought the PM was lying to me when she showed it to me. I was like, it just can't be this easy my others no way but it actually was just as easy as she called command. There's an associate at API call you give three pieces of information when you create your cluster the KMS key location the KMS key ring and a KMS key. You're telling gke the Google kubernetes engine. Please encrypt my secrets with this Cloud cam as key and all of that set up and showed you before that's all done for you automatically. What does brexit interesting question which is how does

kubernetes get permission to talk to the cameras provider in the first place? There has to be some exchange on a set of Sanitation and this is where Cloud providers have an advantage because Cloud providers offer identity and access management as a first-class part of their product portfolio. So I am solves that first secret problem or The Last Mile problem. We delegate privileged access management to the cloud providers and then we have a nice separation of concerns that you know don't need I am permission to talk to cam apps do even if someone has access to the VM on which STD is running

still have permission to talk to call Kim at because I think he doesn't need that only the kubernetes API server does. I'd like to know by Alex Bach on stage to talk a little bit about how this works under the hood on gke and the way that we do application-layer encryption. So, please give it up for Alex. Bank itself is very convincing starting my I don't even think I need to be here anymore. But I guess I need to prove something that is actually works. So I'm hoping that

by this point in the presentation you are reasonably convinced that storing secrets in playing tax an STD, even though the underlying disc is encrypted may not be the best security for sure for your organization. And you're wondering how do I enable this additional layer of encryption or additional layer of protection when I'm riding kubernetes in Google Keep An Education, so I will show this in this demo. It's a two-step process. The first step is we need to create crew for graphic tees.

You will find you will find cryptographic key is in the security subsection of Google Cloud platform. When you land they are you will not if there is a concept of keyrings that is introduced by Cloud cam s t rings are analogous to directories in the file system. You can grow together logically related keys and for example apply. I am policy at the key ring level as opposed to managing individual keys. what you will also notice is that key Rings allocation specific babe attached to a specific location and what

it is important for us to know that they Are kubernetes cluster will need to communicate with Cloud cam as and basically whenever and we want the bad connection to be as quick as possible. So you want to call like eight your kubernetes flossers and you 4:00. MST is in the same region. So let me critiki Let's try to find a meaningful, Maine. And you know what, the defaults will actually are just fine for us before he created. The only thing I will point out to make the previous discussion about irritation with more concrete is this parameter here

rotation. Which is by default 90 days, but you can see that you can set it to whatever makes sense to your organization. take so let me go ahead and quick create. All right, so that takes care of the prerequisites work and now I'm ready to switch to kubernetes engine and I will create my cluster. In order to enable The Fishery. We need to expand availability of networking Security in additional features section. And I need to scroll down to security stop section and check enable application layer encryption. Just a quick

note on terminology in this talk. We use the term at Cydia level encryption quite a bit and I think it's a very pragmatic way of thinking about it. But the reality is that at city is an appointment Asian GTL in kubernetes kubernetes is designed to be agnostic to the configuration database to generic name for this. Hopefully this will help you when you're ready recommendation on the T-shirt. You will see the term application layer encryption as opposed to it as opposed to a to d level encryption. So now that I check this option. You can see that the URI team

has done a great job. And what do you want has done for me in the background? It enumerated all the keys in the projects that need the requirements for this feature. So I only have one so I'll go ahead and select that. And this is another interesting thing is that I get a warning here that sell my information for missing only key you never explain what those I information so are and why do we need them when we go back to the slides, but for now just say that the kubernetes service each an account nice in crib decree privileges on those keys and I have this

all I need to do is just leave this front button and the problem is not resolved. All they need to do now at this point is just keeps create. Sew-in while the cost of a speeding up. I would like to switch back to the flight. And talk about the T-shirt under the hood a little bit. Let's review the components involved. Let them use the components involved in the encryption process. However, this time we'll go over there was components from the threat modeling point of view. The better reason about this rap model, we will classify components involved as either volatile

everything about the dog flying or persistence and everything below the line. 2D Be persistent resources. We assume assume that attackers have full access to anything on the persistent drive for the sake of argument. Let's assume that attackers were able to get a copy of the other two branches Master VM. Of course, the main point of interest for us is the STD datafile. However, we are not limited to we are noticing that accept access only today at city data file anything on that persistence Drive,

which may help a doctor's to decrypt secret or Sofia game. We need to protect against those scenarios. So this introduces the what I call Last Mile problem and staff management staff goals that differ secret problem, but they all point to the same thing. When you look at the diagram, if you can see all the obvious that can mask login needs to authenticate to clock him a service. So this implies that can match login used to have some sort of credential. In order to negotiate in all stalking to present o clock EMS like it was pretty much everything else and go

go plus with you or strata call in order to for identification purposes. So what is an attacker? What if it persisted did Prudential or the resulting talking to disc? Well in this case attackers would actually have everything they need in order to decrease our secrets because they have access to the protected SD data file, but they also have a talk in or its credential to speak to clock a mess and volcanoes by virtue of being a service office ways accessible over public internet. So it's important to make sure that we are not leaking while I'm jumping ahead

to write so Decor design is to ensure in a frat model that attackers it is okay for attackers to have access to that so you didn't fall but they should not have access to anything else that's with allow them to bootstrap communication with the cloud chemist. And in the next several flies, I will explain how we made this objective. This will be a review for most of you, but I wanted to make sure that we are on the same page, and I wanted to explain some Concepts about GT. Most of you probably already know this, but let's please please allow me a couple of

minutes ago. So you probably already know that Google candles all of the details of running kubernetes Masters kubernetes Masters reside in Google manage infrastructure in Google manage projects. However, LS known fact is that when you enable GPU API in your project? A service account which refer to is kubernetes is kubernetes service agent account is creative somewhere else in Google manage infrastructure. And that service account is granted some IM privileges in the customer project.

What why what when was thinking about the process of creating a cluster GTE needs to perform operations specialist create a virtual machine created firewall rule create a persistent disk, obviously, all of this operation requires security context and yes, it is through this service account veggie key access resources in your customers. So that's what's just a review of said the plane for the next discussion. So what about all TMS Keys? How do we access those? Well, you saw in the demo that the expectation is that

you customers create those keys ahead of time and you grant the encrypted free privileges on those keys to kubernetes service station account. You saw me just clicking that button and the you I fix that for me that was kind of magic, but you can certainly do this in a different ways. For example, you can go into the Coliseum asked you why and just use I am and Grant permissions there or you can use g-cloud commands. You may be thinking that was very simple after that was a very simple operation to create that key. Why couldn't you just in bad

this into the consecration process what we certainly consider doing this but decided against list which felt that demon GT the ability to create this very security-sensitive artifacts in your projects. What gives Ukiah way too much power and also tell Dad that would break the segmentation between GT and plow TMF. Therefore we expect that you customers Credo skis and allow us to use them for the purpose of this feature. The remaining piece of the puzzle how does clock it actually

authenticate to clock him a service? So this is gone by communicating with an internal talking service, which is again managed by Google and then talk internet walking service requires. Kmfy again to prove that. It is a member of a cluster that is linked to the corresponding service account. For example, I'm trying to negotiate access to crisp turkey not me because get masked rider negotiate access to that creep turkey and what will try to figure out are you in fact running on that Gloucester that is linked to that service account that you bring a service station account. And

if you can prove this to me, then I will give you that talking. so we don't have time to go through the process management protocol hear it but it is sufficient to say that the stalking service has full knowledge about the master components and it can make that decision of whether granting or denying me access based on the information in the database that it has access to assuming that everything went fine. So I can service was satisfied with the fact that the MS wagon runs in the right posture. It will grant this all stalking

which is now the American president to the encrypted cryptic story again presented. They close DMS service. This is not persist it to disk with storage memory and we we give the key MS Walk in this report. It will just go through the same dance once once again by the time we actually Story 2 Disc. and that is called we actually and then it's called we met our initial objective. We do not store credentials on disc and we do not store the resulting talking's to disc which allows us to meet our

threat model. We are all that I can get is just a CD with encrypted it was encrypted secrets. Okay, this is my last flight and I'm going to change the subject just a little bit and I want to talk about how to run clock EMS login outside Yuki. So even though we hope that you use in GTA to run to burn it is we understand for some of you may be using Google compute engine the amps as the infrastructure to run to burn edges. And the question is can we see the same security contract when running

outside Yuki and the answer is yes. It just simply the caches that are simply more work to manage and set it up. Call Kim s wagon is developing open source, you have a link here to the repository and then the same repository you will find instructions on how to set up clock in a slug in outside kubernetes when writing on GC. Architectural it looks very similar the core difference being a course that there is no kubernetes service Asian account instead. We rely on the service account in the security context of which surrounds the gcvm.

You probably know that when you create it you can also say it was a service account and by virtue of this Association gcvm can impersonate a service account with the same process you create a service account you create Keys you Grand service account in cruelty-free privileges on the key and then you start the gcd. I'm in the security context of that of the service account from that point on everything was the same but they just a lil bit more work and then you have to Manish Manish it from that point on. This is all I had was that it would like to invite South back on stage.

Thank you. Thank you Alex, but you were going to security right? So there's one thing you never trust someone who works in security products. So, how do I know you just didn't fake that GTA thing? Like how do we know that application layer encryption is even enabled on that Direction with cl to create himself and they just didn't show that the recording for all we know right? Could we switch to the damn again? All right. So the gods Rd Freight I'll guess which is a good

sign. All right, but that was a classic that we created a few minutes ago. So what is the visual indication that you have a cluster with that t-shirt abled social scroll down a little bit. You will see application layer encryption and you can see it's enabled and Keurig in you have a link if I pull of this link. It should take me to the cryptographic key that we created in the first step. and Furious where you can manage the key, like for example the options available to me are disable destroy and Steph talked

about Critter shredding if I wanted to kill that class the right now, all I need to do is just destroy that key and essentially It will not be possible to create new secrets on the closet, which I'm not sure if I recommend this option, I would probably just delete the closet in the first place, but it is something that need to be aware of. Anyways, I think you have enough question for you, though the spot we were waiting for some updates and kubernetes 113th. We should not allow us to enable encryption on existing clusters.

That is correct. Super cool. Thanks Alex we go back to the sides, please. So we know that many of you might be on Prem you might be on another cloud provider. You might be doing all of those things. And you may already be using a Secrets management tool like hashicorp Vault. So what if you're not on a cloud provided community service, what's your not on gke? What if you're not entirely on how can you protect yourself against, you know these types of attacks where an attacker has access to the

SUV back up or an online at TD database so you can leverage something like hashicorp Vault to do this and it looks very similar to what we already described. So instead of Google Cloud cam as we throw hashicorp vault in the mix specifically were using hashicorp Vault Cloud Transit Transit secret engine if you will the secret engine is very similar to KMS provider. It has Key Management rotation upgrading downgrading excetera. It looks very similar to what we just drive before the secret data is given to the communities API API server than delegates to the

encryption configuration the encryption configuration then makes an API call to something like hashicorp Vault The Vault Transit back in and Crips that data or decrypts that data before it is written back to SED. So this is a great opportunity. If you have multi Cloud strategy, if you're leveraging, you know, multiple calls MultiCare bonetti's clusters. This gives you a very consistent way in order to encrypt your secrets with an existing Secrets management solution. So very quickly electric show you what that looks like and show you what the data in SED looks like if it's

encrypted with something like hashicorp Vault or Google Cloud cam s can we jump over to the Sloppy toppy, please cool. So what am I to do here is Create secret vault so I have a mini Coupe cluster the same one I had before but this time I added an encryption provider configuration to encrypt Secrets will have to go evolve before writing on tattoo. I could have done this Google account and even another Cloud providers can mess but I'm using volt locally to Showcase kind of a third-party open source told now, I'm going to go ahead and try to access that secret. You'll notice that we don't

get back to the plane Text data. So even though I had the same secret usernames that Fargo password secret and leet this is what I get back. I get back everything cryption prefix the vault key rhyme using and then a bunch of data that my terminal can't even print for you. So if an attacker has access to a CD or has access to this plane text Data, this is what they would get my they want. They don't get the Playtex Secrets. They get those encrypted data in this example here shows what it looks like. I'm not sure if on Google Cloud you had access to the underlying at TD data. It would

look very similar to this if you were using application layer in cryption, the end of the place at Stater would not be available to you. Twitter back to the side real quick to conclude his 1.10 and later introduced some really great features that make it easy to be secure with kubernetes secrets. Always use layered encryption use full disk encryption operating system encryption combined with something like application layer encryption. Rotate your keys regularly both on a schedule and in the event of a data breach.

Leverage on the Living Christian. It's an incredibly scalable way to perform encryption. Enforce use an external cameras provider wasn't that something like Google, cameras or something like hashicorp vault as it requires an attacker to compromise multiple systems in order to gain access to that plane texting.

Cackle comments for the website

Buy this talk

Access to the talk “Securing Kubernetes Secrets (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “Google Cloud Next 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
163
app store, apps, development, google play, mobile, soft

Similar talks

Gabriela Ferrara
Developer Advocate at Google
+ 4 speakers
Dave Nettleton
Director Product Management at Google
+ 4 speakers
Alok Pareek
Founder/EVP Products at Striim
+ 4 speakers
Codin Pora
Director of Partner Technology at Striim
+ 4 speakers
Tobias Ternstrom
Director, Product Management at Amazon Web Services
+ 4 speakers
Available
In cart
Free
Free
Free
Free
Free
Free
Terrence Ryan
Senior Developer Advocate at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Martin Omander
Program Manager (Developer Advocate) at Google
+ 1 speaker
Adam Ross
Senior Developer Programs Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Securing Kubernetes Secrets (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
567 conferences
23025 speakers
8619 hours of content
Alexandr Tcherniakhovski
Seth Vargo