EP48 Confidentially Speaking 2: Cloudful of Secrets

Security. 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. Anton, we're opening year 2 of the show much as we opened year 1. We're talking with Nelly about confidential compute. How cool is that?

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.

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 problem.

Correct. Even with confidential compute, you can still create a badly written app. Hi, Log4j. That would defeat pretty much every safeguard you put around it. Yes.

Also today I learned it's pronounced Log4j.

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

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

Thank you so much for inviting me.

Nelly, we chatted nearly a year ago now, and you were our first guest. It is an absolute pleasure to have you back talking 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?

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 processing. And when they process the data, they keep this data in memory. So, how we do that? We 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 slightly different story, and everybody familiar with that, I guess. And confidential computing, as you said, it's new addition to this lifecycle of data protection that we are really, really worried about and need to help our customers and users to get right.

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.

Yes, that's right.

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?

Last year, when we started, we introduced the first product in confidential computing. It's called Confidential VMs. And it means customers that bring 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. It's 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 2 types of customers. First, customers that are deploying infrastructure and creating clusters, and they have a very simple way, literally one flag or one checkbox to create clusters where every single node pool is confidential. And developers, they can develop their application and package it 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 available to roles, developers that develop apps, and IT and DevOps that provision infrastructure. So, it's about Confidential GK. So, we added an additional product to our portfolio called Confidential Dataproc. And it is because our customers love to run analytics. They need to run Hadoop and Spark in a multi, multi-complicated, multi-node cluster. So what we've done, we offer to our customers confidential Dataproc. Now they can run confidential MapReduce 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 hardware, more sophisticated, more performant, 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.

That makes sense. And I think coverage of services beyond just virtual machines is an obvious step we've taken, right? Because clients obviously don't just wanna run VMs in a 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, customer or 2, perhaps even without naming names, who really nailed it with confidential? Have you seen any epic use cases, some things that worked really well with what you have?

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 they 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, want to move to the cloud as everybody else and hold their database of secrets and keys in memory in the cloud. And they found that it's very interesting and incredibly performant. They need both security and performance, very low latency access with huge QPS access to their vault. And it's what they were able to provide utilizing confidential computing. And they published a very interesting blog, highly recommend to read. What is the use cases and how and why they selected confidential GCP for these purposes. So, it's, I would say, one set of patterns when customers need to protect their secrets, keys, certificates, a 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 customers that are trying to progress and support private and public ledgers. And those sensitive operations 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 transactions in confidential environments. So Block.one, for example, published a blog, how confidential environments in GCP helping them to accomplish the goal. As a 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 again, we hear from gaming companies, and those gaming companies trying to figure 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 combining the virtual and real world. So there is a lot of discussion, and you can think about the variation of blockchain technology with NTF and other tokens, and how to ensure that those specific non-fungible assets can be associated with the digital instances, and how we will track it and ensure integrity and confidentiality of those transactions.

Can you count it as a blockchain episode now?

Oh my God.

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

She might be our First guest to invoke blockchain.

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.

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

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 is 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 name, 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 holding their very, very sensitive private datasets and they have to join it, have to run some algorithms on this joined sensitive data. These guarantees that none of them will have access to the pure data. So, those interesting technologies that before was not possible to accomplish that. And the 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 type of use cases that our customers bring into us without waiting for homomorphic to become fully general computing available or some specific privacy-preserving algos that very interesting been very useful, but also very narrow in the way how they can be applied to. So those use cases coming in tons, and we're interested to see how we can help our customers to get this done.

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 that seem to indicate that this is coming to life very nicely and it's delivering value to clients. In the areas where maybe they couldn't do it before, they could do it only in some inferior way. What about the other question I asked 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're dealing with? What do we know here after a year?

What we know after a year, and probably more than a year, Anton, is that threat modeling is not the only thing why customers are interested in confidential computing and encryption at, again, all different stages. There are compliance and regulation requirements that they need to meet. And despite the fact that Confidential computing is the new kid on the block and not part of these regulations. But every single regulation is defined in very generic terms. In particular, California Privacy Act last year saying, okay, you need to encrypt your data end-to-end and go figure out what does it mean. So, a lot of our customers relying on their own way to interpret GDPR and HIPAA and all other regulation, and confidential computing becoming yet another layer of protection. As this, again, in-depth layers that customers putting in place to ensure that their data not accessed again, and they can minimize the risk of exposure. Because all of our customers understand that Encryption helping 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's eliminating 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 worrying 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 collaborate, as I mentioned earlier, that before was not even 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 environment, but we cryptographically isolated environments. And isolation between tenants and us, Google, that also helping to ensure that our zero-days will not make our customers suffer. All of that is super useful. But the things that we found becoming more and more interesting to our customers is to connect the dots between these different encryptions.

Hmm.

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'm 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 customers asking us, okay, how we will ensure that this key and data never seen in clear text by Google. And then confidential computing can help to connect the dots. Next, we introduced this interesting concept that we called Ubiquitous Data Encryption together with Thales, when Thales can hold the keys and customers can encrypt the data outside of GCP. And we ensure to share those keys encrypted Only and only these confidential environments, after confidential environments can attest themselves to Talos, to external key manager, that they actually confidential. So connecting these dots and making this very interesting way of key distribution in new world, we helping customers to protect the data end-to-end. And it's exactly what they're looking for. And it's where they interested, not in confidential computing in isolation, not external key manager and isolation, but all of that connected together and preferably easy to use. So, it's where we are going and what we are looking forward to enable our customers to take advantage of.

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, and I'm sure there are more coming. What are the other challenges in, you know, like getting it right?

Multiple challenges still there for our customers because we need to understand that it's not only encrypting data, but also protecting your workload. One of the interesting challenges that customers, and no surprise, is the Log4j and all other interesting big games, SolarWinds, everything is pointing out that what is the code, what is the application that 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 binary authorization. But the whole idea is very basic. If I care about my data and I want to process it securely, how will I ensure that the application code algorithm, my model, is actually trustworthy? How to ensure that it was built properly? I understand the provenance, I understand who touched it, I know that every single time when I tested 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, the whole this world of software supply chain, is very tightly related to how we will protect customers' data and customers' workloads. And it's one of the challenges that all of us need to be able to help our customers to address.

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

Yeah, badly. I think you can write a fairly bad app that's vulnerable, breakable, and I don't think memory encryption and In-process encryption would like solve all of your problems, just like network encryption wouldn't fix you 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. There's a lot more fun stuff you can do wrong in AppSec. And yeah, that's very much our future, I guess.

You are absolutely right.

Yes.

Yes.

We've had many a conversation on the podcast now about the intersection of infrastructure 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?

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 work in progress, to provide the environments of this black box, this chamber that they can run, but it cannot be modified. And it's complication because now you need to run those environments and redone it every single time you need to change. But it guarantees that nothing, even when you have high-value permissions, would be able to modify your environment. So, we have opportunity to work with that. But also, we can work with developer tools. We need to ensure that, for example, open source, again, GitHub and everything, delivering verifiable binaries and verifying builds. We need to ensure that all build tools. We have our own GCP Cloud Build tools, for example, that we can validate and attest, 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? It's what we call code provenance, one of the areas that we work in really, really serious with open source community, other vendors to ensure that we can specify metadata, all this code provenance capability, with the package itself. It can be validated. So, as soon as you know identity of the code, you know where it's coming from, who built it, who accessed 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. Cloud Build, Cloud Deploy, and other services that 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 their best jobs without becoming professional in every single aspect of this journey.

That makes sense. And I think that now that we are 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 even called it ubiquitous, not invisible encryption, right? 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 confidential compute and EKM, where you have the keys in your hands?

I would say that customers that want to encrypt the data and hold their own keys are the right customers for this particular solution.

So every EKM customer should use EKM+Confidential then, right?

Absolutely.

Okay, got it. Makes sense.

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, Then 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.

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 wanna ask, just looking ahead, because it's easy to predict things, and especially easy to predict the future, what's coming soon? What should people look forward to?

So, with confidential computing, we want to ensure that we will address all of those different areas that I discussed, because some of them are still work in progress. We need to ensure that our new attestation model will include attestation of the application that's running in your confidential environment, and it's also 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 live migration. One of the best things that our customers are so used to deal with when we're patching their hosts, Due to whatever reason we need to patch the host. So all of this work is definitely work that all my teams are focusing on, and we hope we will bring more and more capability in confidential computing to our customers soon.

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

So the first question, I would suggest to read a few papers, white papers, that 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 CCC very recently. So, it's what I would suggest people will read if they're actually looking for some fun reading during holidays. And the second question about, okay, what to do and how to get familiar with it, to 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 with that. If it will not be something of your, again, 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.

Are you missing the step and then try to hack them? Because it is a security feature, right? I'm not confused, right?

The number 4, if you're more than welcome To hack it and report to us anything that you will find. So it's absolutely across all of those efforts. Yes, more than welcome. Hack it. Again, play with that, see how it will work. Check your performance, your latency, your everything that you need to see that it actually can help you to address your real problem, real things that you are looking for.

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

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

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/cloudsecpodcast. And of course, your hosts are also on Twitter at Anton_Chuvaikin and _TimPeacock. Tweet at us, email us, argue with us. And if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode. And of course, welcome to 2022. We are recording this at the very end of 2021, but this would be Air in January, so hopefully this year would be the better one.

Security.