EP48 Confidentially Speaking 2: Cloudful of Secrets

Tim: Hi there. Welcome back to the Cloud Security Podcast by Google for our second year. Thank you so much for joining us today. Your hosts here have not changed. It's still myself Tim Peacock, the product manager for threat detection here at Google, and Anton Chuvakin, a reformed analyst, esteemed member of the cloud security team here at Google, and really the heart and soul of the podcast. You can find and subscribe to this podcast in all the same places as last year, as well as at our website, which we are proud to have going into our second year, cloud.withgoogle.com/cloudsecurity/podcast.

If you like our content, and now that we're back releasing again, every Monday, you can hit that subscribe button on your app of choice. As always, you can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we're opening year two of the show, much as we opened year one. We're talking with Nelly about confidential compute. How cool is that?

Anton: It's pretty cool. And it also allows us to know what changed in a year in this exciting area, right? Confidential computing is kind of fun. It's fun from both computer science point of view, it's fun from operational point of view, and it's fun from a threat model point of view, my favorite point to make, of course.

Tim: It has a fascinating threat model because, at the end of the day, it's like a lot of things in cloud security. If you have an AppSec problem, you still have an AppSec.

Anton: Correct. Even with confidential computer, you can still create a badly written app, hi log4J. That would defeat pretty much every safeguard you put around it. Yes.

Tim: Also today I learned it's pronounced log forge.

Anton: Oh, that's a fancy French way to pronounce it, I'm pretty sure.

Tim: Do you think we'll still be talking about that when this episode comes out in January? I think so. Well, listeners with that blast from the not-so-distant past, let's turn it over to our guest, Nelly Porter, our group product manager and dear friend to this here at Google Cloud.

Nelly: Thank you so much for inviting me.

Tim: Nelly, we chatted nearly a year ago now and you were our first guest. It is a absolute pleasure to have you back talk to us once again about confidential compute. For something so game-changing, it only makes sense to have you back to, again, open our season talking about this. You might not know this, but your episode has been an enduring fan favorite, I think in part, just because of how esoteric and bizarre and awesome it is, what we're able to do with confidential. Could you remind us what confidential compute is? And then tell us what's new.

Nelly: First of all, thank you so much for having me to your first episode of the next year. Happy new year, everybody, listening to our podcast, and let's come back to confidential computing. So confidential computing it's ability for people to encrypt the data when it's processed. And when they process the data, they keep this data in memory. So how they do that to encrypt memory, so your data always encrypted when you need it, when you index it, infer, train on it, do anything useful with this data. Again, we encrypt the data when you store it. It's like a different story and everybody is [inaudible], I guess. And confidential computing because it's new addition to this lifecycle of data protection that we really, really worry about and need to help our customers and users to get right.

Tim: To summarize, confidential compute gives users the ability to have their data encrypted, not only in transit, not only in rest, but also in use.

Nelly: Yes, correct.

Tim: That's amazing. So what's new since we talked about this a year ago? What are the new exciting capabilities we've got with confidential? I saw a bunch of releases, but I didn't keep track of what they all were. So what's changed?

Nelly: Last year when this started, we introduced the first product in confidential computing. It's called confidential VMs. And it means customers, they brings their VM instances to GCP in what we call general purpose. It means you can run anything from databases to some other jobs in VMs can utilize confidential VMs, but we moved beyond that, as you said. And first and foremost, we know that customers not only are running VMs, but they're also running Kubernetes. And we have managed Kubernetes solution in GCP called Google Kubernetes engine, GKE. And we introduced confidential GKE to our customers. Right now it's in public preview and we're very rapidly moving it to general availability.

But the cool thing about this particular offering, we were thinking about two types of customers. First, customers deploying infrastructure and creating clusters, and they have very simple way, literally one flag or one checkbox, to create clusters where every single notebook is confidential. And developers can develop their application in packages in Kubernetes in containers, and they can specify that this particular container or pod is sensitive and needs to run on confidential cluster. So now we have confidential GKE well-built for developers. It's a developer app, and IT, and dev ops that provision infrastructure. So it's about confidential GKE.

So we added additional product to our portfolio called confidential data product. And it is because our customers love to run analytics. They need to run Hadoop and Spark in multi-multi complicated multi-node clusters. So what we have done, we offer to our customers' confidential data product. Now they can run confidential rapid use or Hadoop or Spark jobs in fully confidential environments. So to summarize, we continue to do a few things. We're moving confidential computing to newer [inaudible], more sophisticated, more performance, and also we're increasing the set of GCP managed services that can take advantage of confidential computing and address specific use cases that our customers want to bring to GCP.

Anton: That makes sense. And I think coverage of services beyond just the virtual machines is an obvious step we've taken, because clients obviously don't just want to run VMs in the lift and shift scenario, but do some glamorous, cloudy stuff in the cloud and do it securely. So while we are on this topic, could you talk about a user, a customer or two perhaps even without naming names who really nailed it with confidential? Have you seen any epic use cases, some things that dropped really well with what?

Nelly: First of all great question, Anton. I will not be able to mention too many names due to confidentiality, no pun intended of our customers, but a few interesting patterns with some customers that blogged about how to use confidential will be interesting. So first, again, we published a blog about HashiCorp and ability for them to utilize confidential computing to protect secrets. As you probably know, HashiCorp Vault is using in-memory secrets for very many customers' workloads and applications, and HashiCorp, no surprise, wants to move to the cloud as everybody else and hold a database of secrets and keys in memory in the cloud. And they found that it's very interesting and incredibly performance syncing both security and performance, very low latency access with huge QPS, access to the Vault. And therefore they were able to provide utilizing confidential computing and they published very interesting blog, highly recommend to read, Vault is use cases and how and why they selected confidential GCP for this purposes.

So it's, I would say one set of patterns when customers need to protect their secrets keys certificates, the private portion of those certificates, and want to ensure that it's running in confidential computing. The second set of customers, and we also had one blog about those types of customers is our blockchain customers. So we have very many, I guess, where they're trying to progress and support private and public ledgers, and those sensitive operation of signing, modifying the blocks of this ledger has to be done in confidential environments.

And we've seen quite a lot of customers interested to protect those operations, those transaction in confidential environment. So Block.one, for example, published a blog on how confidential environments in GCP is helping them to accomplish the goal. The third one, we've seen quite a lot of interest coming from, and now I will surprise you, again, technology and verticals that we never would think about and gains we hear from gaming company. And those gaming companies are trying to figure it out, and it's, again, the conversations that we have today, and it's one of the biggest surprises and discoveries for us, how to deal with these combining the virtual and real world. So there is a lot of discussion, and you can think about the variation of blockchain technology, these MTFs, and tokens, and how to ensure that those specific, not tangible assets can be associated with the digital instances and how we will track it and ensure integrity and confidentiality of those transactions.

Anton: Can we count this as a blockchain episode now?

Tim: Oh my God.

Nelly: No, no, no, no, no, no, no. It's still confidential computing.

Tim: She might be our first guest to invoke blockchain.

Anton: I think it's official. We have a blockchain episode now here, this one. Sorry for the interruption, but of course, this is like an epic moment. We just featured blockchain.

Tim: It took us a year to get here. It's amazing.

Nelly: It will become more and more interesting. No apology, Anton, because more and more big financial companies are looking for, again,, thinking about crypto, and crypto, not only cryptography end-to-end, but it's, again, specific blockchain technology for their specific use cases. So we see that coming. And the final area that is it becoming more and more evident to us and more and more interesting, I guess, to our customers, what confidential computing was able to do that before they couldn't make happen. And we talk about that as, again, sometimes very boring theme, untrusted multi-party computation, and more friendly name for the same technology is called federated computation.

But the problem is very, very old and well known. You have multiple companies holdings the very, very, sensitive private datasets, and they have to join it, have to run some algorithms on this drawing* and sensitive data with guarantees, and none of them will have access to the pure data. So those interesting technologies that before was not possible to accomplish that. And reason why, because to be able to do it, the only things you can do is to utilize privacy, preserving protocol that's very, very specific to very specific need and operation, and also fully homomorphic encryption is still not there for us. So confidential computing is a first step to unleash those types of use cases that our customers bring to us without waiting for homomorphic to become fully general computing available or some specific privacy-preserving algos that's very interesting and very useful, but also very narrow in the way how it can be applied to. So those use cases are coming in tons and we're interested to see how we can help our customers to get this.

Anton: I think that makes sense. And of course, when we spoke last time, you kind of said a lot of this is in the future and I'm super happy to hear the stories. It seemed to indicate that this is coming into life very nicely and it's delivering value to clients in the areas where maybe they couldn't do it before, or they could do it only in some inferior way.

What about the other question I asked for the first time, namely about threat models? One thing that we hypothesized is that some customers want this because they have a threat model in mind. Maybe they're afraid of Google, maybe they're afraid of some government somewhere, but what did we learn about the threat models in this area? What did we learn for what security problem they're solving, what threats they're mitigating, what risks they are dealing with? What do we know year after year?

Nelly: What we know after a year and probably more than a year, Anton, is the threat modeling is not the only thing why customers are interested in confidential computing and encryption at, again, all different stages. There is compliance and regulation requirements that they need to meet and despite of the fact that confidential computing is indicated on the blog and not part of these regulations, but every single regulation is defined in very generic term, in particular, California privacy last year saying, "Okay, you need to encrypt your data and land and go figure out what does it mean"

So a lot of customers rely on their own way to interpret GDPR and HIPAA and other regulation. And confidential computing becoming yet another layer of protection is this, again, in-depth layers that customer's putting in place to ensure that their data is not accessed again and they can minimize the risk of exposure, because all of our customers understand that encryption help in multiple ways for them. Again, I'm talking about encryption end to end, not only confidential. And it's, again, sometimes it's separating roles, who have access to the keys. In other places, it is to eliminate the enormous amount of data that they have and ensuring that now, instead of worrying about who has access to the data, they can start to worry about who has access to the keys.

And the third, it's again, trying to protect access in general and visibility of sensitive data. And collaboration as I mentioned earlier, before was not possible. The security guarantees that we provide in confidential computing is providing much stronger isolation, isolation between different tenants, because now we not only virtualize the environment, but we cryptographically isolate the environment. And isolation between tenants and us Google that also help to ensure that zero days will not make our customers suffer. All of that is super useful. But the thing that we found becoming more and more interesting to our customers is to connect the dots between different encryption. I can encrypt my data at rest or everywhere outside of the cloud. So I hold my key. I'm super happy with that because I meet my regulations and I ensure that only me and my personnel has access to the key. So now I am bringing this encrypted data to your storage services, your storage GCS buckets or whatever, and now I need to process it

Then the biggest question that customer is asking now is, okay, how we will ensure that these keys and data never seen in clear tasks by Google. And then confidential computing can help to connect the dots. Next, we introduce these interesting concepts that we call ubiquitous data encryption. Together [inaudible] when tell us can hold the keys and customers can encrypt the data outside of GCP and they ensure to share those keys encrypted only and only in this confidential environment after confidential environments cannot turn themselves to tell us, to external key manager that they are actually confidential. So connecting these dots and making these very interesting way of key distribution in new Vault, we're helping customers to protect the data end to end.

And this is exactly what they're looking for and it's what they're interested not in confidential computing in isolation, not external key manager in isolation, but all of that connected together and preferably easy to use. So it's where we're going and what we're looking forward to enable our customers to take advantage of.

Anton: That actually leads right into the next question I wanted to ask, which is what are the challenges people face adopting it? It sounds like one of those challenges is moving the data around securely, moving the keys around securely, having assurance that keys are only where they belong. What else are we doing to help make this easier for people? It sounds like we've got a partner involved in, I'm sure there are more coming, but what are the other challenges in getting it right?

Nelly: Multiple challenges still there for our customers because we need to understand that it's not only in creating data, but also protecting your workload. One of the interesting challenges that customers and no surprise is a low core J and other interesting, again, solving every everything is pointing out. What is it called? What is the application? Is it accessing my data? How to ensure that these applications and those services I can trust. And this is a problem that we call secure software supply chain. It's one of those that Google was spending enormous amount of time and effort for our internal infrastructure. And we brought it to our customers as part of [inaudible].

But the whole idea is very basic. If I care about my data and I want to process it securely, however, ensures it's an application called algorithm. My model is actually trustworthy, how to ensure that it was built properly, I understand the providence, I understand who touch it, I know that every single time when I test it nobody added anything to that. By the way the latest nightmare of our existence it was specifically modified to make it vulnerable. I'm talking about the recent few days ago trouble. What I'm trying to say is the whole this vault of software supply chain is very tightly related to how they'll protect customers' data and customers' performance. And it's one of the challenges that all of us need to be able to help our customers to address.

Tim: That makes a ton of sense that application security remains a challenge, even in a confidential world.

Anton: Yeah, badly. I think you can write that fairly bad app that's vulnerable breakable. And I don't think memory encryption in process encryption would solve all of your problems, just like network encryption wouldn't fix. You're not making an encryption call or leaking data around the encrypted channel. There's a lot of stuff you can do wrong in NetSec. And of course, AppSec is frankly worse. A lot more fun stuff you can do wrong in AppSec, and yeah, that's very much our future, I guess.

Nelly: You're absolutely right, yes.

Tim: We've had many conversations on the podcast now about the intersection of info security and application security, and whether that's better or worse in the cloud. I don't think we've come to a firm answer on that, and I don't know if we will today, but it remains an interesting area for us. On that front though, are we providing secure blueprints? Are we providing guidance? Do we have PSO going on? How are we helping users get this right?

Nelly: I think we're doing all of that that you said, Tim, and we're doing more than that. For example, if I'm bringing back to confidential computing, one of the areas that we want to help our customers to create is immutable environments. And imagine if it would be possible for us to, again, it's something that's still a work in progress, to provide the environments of these black boxes, these chambers that they can but it cannot be modified, and its complication because now you need to run those environments and we have done it. Every single time you need to change, but its guarantees is nothing even when you have high-value permissions would be able to modify your environment.

So we have opportunity to work this out. But also we can work with developer tools. We need to ensure that, for example, open-source, again GitGHub, and everything delivering verifiable binaries and verifying built. We need to ensure that all build tools, we have our own GCP cloud build tools, for example, that we can validate and test, but we also want to extend it to Jenkins and other build tools that our customers use.

How to ensure that we understand where code is coming from is what we call code provenance, One of the areas that we've working in really serious is open source community with other vendors to ensure that we can specify metadata or this code provenance capability, this package itself that can be validated. So as soon as you know identity of the codes, you know where it's coming from, who built it, who access it, and how it was modified before it would be deployed, it's all of those topics that we want to help our customers with our cloud build, deploy, and other services we will offer as we go. So it's not only, as we said, shared responsibility when customers need to follow our best guidance and blueprints, but also tools that will help them to do the best job without becoming professional in every single aspect of this job.

Anton: That makes sense. And I think that now that we're starting to get close to the time on this episode, I wanted to ask one particular question connected to this. I've heard, of course, that we finally married confidential computing with our external key manager or EKM technology. I think we haven't called it ubiquitous, not invisible encryption. So what types of clients are looking to deploy that particular use case of confidential computing and what threats are they mitigating? When do you need conventional compute and EKM where you have the keys in your hands?

Nelly: I would say that customers that want to encrypt the data and holds their own keys as the right customers for this particular solution.

Anton: So every EKM customer should use EKM plus confidential then, right?

Nelly: Absolutely.

Anton: Okay, got it. Makes sense.

Nelly: If they want to do something with the data. So if they want to hold the data or store the data, or keep storage as a backup, confidential computing is irrelevant, but as soon as they need to do anything with the data in GCP, combination of EKM and confidential computing is exactly the solution for those customers.

Tim: I love that we just got an answer of, yes, everyone should use that. That's a very simple answer. We don't usually get those on the show. That's nice. I want to ask just looking ahead because it's easy to predict things and especially just predict the future, what's coming soon? What should people look forward to?

Nelly: So this confidential computing, we want to ensure that we will address all of those different areas that I discussed because some of them is still work in progress. We need to ensure that our new attestation model will include attestation of the application of the training in your confidential environment. And it's also a work in progress for us. So to marry, as you said, infrastructure and application security, and make it so much easier for customers to understand, we're looking for extending confidential computing to more GCP services and we're looking to extend it to more CPU vendors and CPU configurations.
We want to ensure that confidential computing will finally support life migration. One of the best things that our customers still use to deal this when we're patchings their hosts due to whatever reason we need to patch across. So all of this work is definitely work that all my teams are focusing on and we hope we'll bring more and more capability in confidential computing to our customers soon.

Anton: Perfect. That makes sense. And we want to ask two of our traditional closing questions, namely, any further region*, any recommended sort of materials to produce for the audience? And of course, one final question is, is there any one practical thing the audience can do, I guess, start to become more familiar or start using confidential compute? It's kind of your choice.

Nelly: So the first question, I would suggest to read a few papers, white papers, published by Confidential Computing Consortium as probably my audience understand and knows that Google is co-founder and big participant in Confidential Computing Consortium. So it was a few very interesting technical papers and even market analysis for confidential computing that was published by triple CCC very recently. So it's what I would suggest people to read, those actually looking for some fun reading during holidays.

And the second question about, okay, what to do and how to get familiar with, have some, again, knowledge, it's very simple. Again, you have $300, I think, of free credits on GCP. Go create your account, go to compute and create a confidential VM and run your application, your Hello World application [inaudible]. If it will not be something of your taste, do the same with GKE or have any, again, Hadoop cluster. And to enable it, it's very trivial. I published quite a few videos and how-to, so more than welcome to try a few examples and see how it will work for you.

Anton: Are you missing this step, "And then try to hack the"? Because it is a security feature, right? I'm not confused, right?

Nelly: The number four, you're more than welcome to hack it and report to us any things that you will find. So it's absolutely across all of those efforts. Yes, hack it. Again, play with that, see how it will work, check your performance, your latency, everything that you need to see that it actually can help you to address your VL problem or VL thing that you're looking forward to address.

Anton: Perfect. Thank you very much for being with us on the podcast the second time.

Nelly: Thank you so much for inviting me to be with you second time. I hope it's not going to the last.

Anton: And now we are at time. Thank you very much for listening and of course, for subscribing as well. You can find this podcast at Google podcasts, Apple podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can also follow us on Twitter at twitter.com/cloud@podcasts. And of course, your hosts are also on Twitter @anton_chuvakin and _TimPeacock. Tweet us, email us, argue with us, and if you like hate what you hear. We can invite you hear. We can invite you on the next episode. See you on the next cloud security episode. And of course, welcome to 2022. We're recording this at the very end of 2021, but this would air in January. So hopefully this year would be the better one.