Today, we are happy to announce that Confidential GKE Nodes are available on compute optimized C2D VMs.

Many companies have adopted Google Kubernetes Engine (GKE) as a key component in their application infrastructure. In some cases, the advantages of using containers and Kubernetes can surpass those of traditional architectures, but migrating to and operating apps in the cloud often requires strategic planning to reduce risk and prevent data breaches. This is where Confidential GKE Nodes can be utilized to enhance the security of your GKE clusters or node pools.

Confidential GKE Nodes leverage specialized hardware to encrypt data in-use and are ideal for organizations processing sensitive data in the cloud. To make it easier to start using Confidential GKE Nodes, GKE standard workloads you run today can run as confidential GKE workloads without code changes on your end.

Security underpinnings of Confidential GKE Nodes

As we expand the Confidential Computing product portfolio from Confidential VMs to Confidential GKE Nodes to Confidential Dataproc, ensuring high performance is key. Confidential GKE Nodes are built on the same technology foundation as Confidential VM and utilize the Secure Encrypted Virtualization (SEV) capability of AMD EPYC™ processors. This feature allows you to keep data encrypted in memory with node-specific, dedicated keys that are generated and managed by the processor. The keys are generated in hardware during node creation and reside solely within the processor, making them unavailable to Google Cloud or other nodes running on the host.

Combined with the high performance of C2D VMs

Previously, Confidential GKE Nodes were generally available only on general purpose N2D VMs, but now they’re also available on compute optimized C2D VMs. The C2D machine series provides VM sizes ranging from 2 vCPUs to 112 vCPUs, offers up to 896 GB of memory, and are suited for performance-intensive workloads. C2D standard and C2D high-CPU machines serve compute-bound workloads including high-performance web servers and media transcoding. C2D high-memory machines serve specialized workloads such as high-performance computing (HPC) and electronic design automation (EDA), which require more memory.

Confidential GKE Nodes on compute-optimized C2D VMs could be a fit for use cases that require high performance and security. You can achieve encryption in-use for data processed inside your GKE cluster or just on specific node pools, without significant performance degradation. This is relevant for industries such as financial services, healthcare, retail, blockchain, and telecommunications, which often have sensitive data or personally identifiable information (PII) that requires additional security measures.

How MATRIXX used Confidential GKE Nodes

MATRIXX Software chose Confidential GKE Nodes to provide transparent encryption for data in-use to supplement encryption for data at-rest to secure personal subscriber data as required by privacy regulations.

MATRIXX Digital Commerce Platform (DCP) is a real-time 5G monetization for the communications industry, serving many of the world’s largest operator groups, regional carriers, and emerging digital service providers. MATRIXX used Google Cloud Confidential GKE Nodes to deliver a cloud-first digital commerce solution that enables commercial and operational agility for current and new telco business models.

A whitepaper titled “Protecting Your 5G Revenue Stream in the Cloud,” described how when MATRIXX DCP is deployed with Confidential Computing on Google Cloud, “its subscriber data, account balances, network events and charges/revenue streams are encrypted in use without making any code changes to the application or compromising on performance.”

Confidential GKE Nodes are globally available

At Google Cloud, we’re committed to investing in Confidential Computing, so we’ve expanded our support to VM families like C2D VMs. Confidential GKE Nodes running on C2D VMs are available in regions across the globe, including us-central1 (Iowa), asia-southeast1 (Singapore), us-east1 (South Carolina), us-east4 (North Virginia), asia-east1 (Taiwan), and europe-west4 (Netherlands). Note that Confidential GKE Nodes are available where C2D or N2D machines are available.

Pricing for Confidential GKE Nodes

There is no additional cost to deploy Confidential GKE Nodes, other than the costs of Compute Engine and Confidential VM pricing.

Try out Confidential GKE Nodes for cluster-level enablement

• First, go to the Google Kubernetes Engine page in the Google Cloud console. In the top navigation bar, click Create. In the Create Cluster modal, choose ‘Standard: You manage your cluster’ and click Configure.
• Next, from the left navigation pane, under Cluster, click Security. Select the ‘Enable Confidential GKE Nodes’ checkbox.
• Then, from the left navigation pane again, under Node Pools, click Nodes. Under Machine Configuration and Machine family, select the Compute-optimized tab, and choose a C2D machine type.

Configure the rest of the cluster as desired and click Create.

Making secure design choices should be easy, especially when the workloads involve high-performance processing of sensitive data. You can help protect your sensitive applications and data today by adding Confidential GKE Nodes to your GKE workloads. Learn more about Confidential Computing here.

I’m excited to share our first Cloud CISO Perspectives post of 2022. It’s already shaping up to be an eventful year for our industry and we’re only in month one. There’s a lot to recap in this post, including the U.S. government’s recent efforts to address critical security issues, like open source software security and zero trust architectures. We’ve also released new resources from our Google Cybersecurity Action Team like the Cloud Security Megatrends and the Boards of Directors whitepaper on cloud risk governance. 

Cloud Security Megatrends 

We’re often asked if the cloud is more secure than on-prem (and why) so we shared our answer in a recent blog post. At Google Cloud, security by design is our priority. We’ve long adopted zero-trust principles for our baseline security architectures and built a global network that relies on defense in depth layers to protect against configuration errors and attacks. But security is always evolving and that is why we also take advantage of the following megatrends:

1. Economy of scale: Decreasing the marginal cost of security raises the baseline level of security. 
2. Shared fate: A flywheel of increasing trust drives more transition to the cloud, which compels even higher security and even more skin-in-the-game from the cloud provider.
3. Healthy competition: The race by deep-pocketed cloud providers to create and implement leading security technologies is the tip of the spear of innovation. 
4. Cloud as the digital immune system: Every security update the cloud gives the customer is informed by some threat, vulnerability, or new attack technique often identified by someone else’s experience. Enterprise IT leaders use this accelerating feedback loop to get better protection.
5. Software-defined infrastructure: Cloud is software defined, so it can be dynamically configured without customers having to manage hardware placement or cope with administrative toil. From a security standpoint, that means specifying security policies as code, and continuously monitoring their effectiveness.
6. Increasing deployment velocity: Because of cloud’s vast scale, providers have had to automate software deployments and updates, usually with automated continuous integration/continuous deployment (CI/CD) systems. That same automation delivers security enhancements, resulting in more frequent security updates.
7. Simplicity: Cloud becomes an abstraction-generating machine for identifying, creating and deploying simpler default modes of operating securely and autonomically. 
8. Sovereignty meets sustainability: The cloud’s global scale and ability to operate in localized and distributed ways creates three pillars of sovereignty. This global scale can also be leveraged to improve energy efficiency.

If you’re an IT decision maker, pay attention to these megatrends that will continue to drive and reinforce cloud security and will outpace the security of on-prem infrastructure well into the future. 

U.S. Federal government cybersecurity momentum 

• Open source software security: Earlier this month, Google participated in the White House Summit on open source software security. The meeting came at a critical time for the industry following December’s Log4j vulnerabilities and was both a recognition of the challenge and an important first step towards addressing it. The open source software ecosystem is not homogenous, despite the fact that the industry often thinks of or treats it this way. Some of it, like Linux, is highly curated, while other critical software is supported through diffuse communities including technology companies and other stakeholders. There is also a long tail of many other critical projects driven by a dedicated community of maintainers around the world, including Googlers. In light of this reality, we welcomed the chance to share our recommendations to advance the future of open source software security. Some work we’ve done includes founding the Open Source Security Foundation, which has been instrumental already in making security improvements. We’ve also helped drive a number of key security initiatives within the open source community including security scorecards, the SLSA framework to improve the security and integrity of open source packages, and Secure Open Source Rewards to financially incentivize improvements to critical open source security projects.  
• OMB’s Federal zero trust strategy: The publication of the Office of Management and Budget’s zero trust architecture strategy marks an important step for the U.S. federal government’s efforts to modernize under Executive Order 14028. Google Cloud supports this approach, which recognizes the immense security benefits offered by modern computing architectures. For the past decade, Google has successfully applied zero trust principles through our BeyondCorp and BeyondProd frameworks for providing end-user access and securing our cloud workloads. And we’ve brought these best practices from our own journey to global governments and businesses of any size through solutions like BeyondCorp Enterprise and capabilities like Binary Authorization and Anthos Service Mesh, which are embedded in Anthos, our managed application platform. For Federal agencies embarking on this zero trust journey, the Google Cybersecurity Action Team will offer our expertise by conducting Zero Trust Foundations strategy workshops, which can help organizations in the public and private sectors develop actionable and achievable strategies and plans for zero trust implementation. 

Google Cybersecurity Action Team Highlights 

Here are the latest updates, products, services and resources across our security teams this month: 

Security

• Democratizing security operations: We recently announced that Siemplify, a leading security orchestration, automation and response (SOAR) provider, is joining Google Cloud to help companies better manage their threat response. Providing a proven SOAR capability with Chronicle’s approach to security analytics is an important step forward in our vision to advance invisible security and democratize security operations for every organization.
• Security by design: The Highmark Health security team is using “secure-by-design” techniques to address the security, privacy, and compliance aspects of its Living Health solution with Google Cloud’s Professional Services Organization (PSO). Google has long advocated for and followed security by design principles, which is why we’re continuously building enhanced security, controls, resiliency and more into our cloud products and services. 
• Secure collaboration for hybrid work environments: The Google Workspace team shared its recommendations for businesses as they prepare for the future of work,  where the hybrid/flexible work model is becoming standard practice and a new approach to security is essential.
• Anthos Policy Controller CIS Benchmark enforcement: A big part of our shared fate philosophy is to build secure products and not just security products. A recent example of this in action is embedding CIS benchmark policy conformance in the Anthos Policy Controller. We believe the more we embed approaches like this into our products, the more application and infrastructure teams can intrinsically embed security at the start and reduce toil for the security team.
• DevOps for technology-driven organizations and startups: A key success factor for many security programs is the partnership and integration with development teams, and there are some great resources and lessons in our DORA research.
• Security by design with Chrome OS: ABN AMRO’s Asia-Pacific region team recently shared how they are using Chrome OS and CloudReady to work securely in the cloud, reduce total cost of ownership, and add flexibility for employees. This is a great example of secure by design principles in the use of Chromium.

Risk & Compliance

• Boards of Directors summary guide to cloud risk governance: The latest whitepaper from the Google Cybersecurity Action Team outlines how boards of directors can prioritize safe, secure, and compliant adoption processes for cloud technologies within their organizations.  
• TruSight Risk Assessment of Google Cloud: TruSight recently released a comprehensive
  risk assessment report on Google Cloud. Our Enterprise Trust team collaborated on this robust assessment of Google Cloud services to validate the design and implementation of controls. TruSight’s risk assessment of our security controls will help customers accelerate and complete their risk management due diligence.
• Data governance: Check out this new blog series on data governance where our teams explain the role of data governance, its importance, and the necessary processes to run an effective data governance program. Implementing data governance will help maximize value derived from business data, build user trust, and ensure compliance with required security measures.

Controls and Products

• Encrypting Data Fusion: To help meet the security, privacy and compliance requirements of customers in regulated industries like finance or public sector, we announced the general availability of Customer Managed Encryption Keys (CMEK) integration for Cloud Data Fusion, which enables encryption of both user data and metadata at rest with a key that customers can control through our Cloud Key Management Service (KMS). 

Don’t forget to sign-up for our newsletter if you’d like to have our Cloud CISO Perspectives post delivered every month to your inbox. We’ll be back next month with more updates and security-related news.

This blog includes content from Episode One “Confidentially Speaking” of our Cloud Security Podcast, hosted by Anton Chuvakin (Head of Solutions Strategy) and Timothy Peacock (Product Manager). You should listen to the whole conversation for more insights and deeper context.LEARN MORECloud Security Podcast – Confidentially SpeakingListen to the Cloud Security Podcast with guest Nelly Porter, Group Product Manager @ Google.

We all deal with a lot of sensitive data and today, enterprises must entrust all of this sensitive data to their cloud providers. With on-premises systems, companies used to have a very clear idea about who could access data and who was responsible for protecting that data. Now, data lives in many different places—on-premises, at the edge, or in the cloud. 

You may already know that Google Cloud provides encryption for data when it is in transit or at rest by default, but did you also know we also allow you to encrypt data in use—while it’s being processed? 

In this podcast episode, Product Manager Nelly Porter gave us a peek under the hood of  confidential computing at Google Cloud. 

What is confidential computing? 

Google Cloud’s Confidential Computing started with a dream to find a way to protect data when it’s being used. We developed breakthrough technology to encrypt data when it is in use, leveraging Confidential VMs and GKE Nodes to keep code and other data encrypted when it’s being processed in memory. The idea is to ensure encrypted data stays private while being processed, reducing exposure.

During the episode, Nelly Porter explained that Google Cloud’s approach is based on hardware and CPU capability. Confidential Computing is built on the newest generation of AMD CPU processors, which have a Secure Encrypted Virtualization extension that enables the hardware to generate encryption keys that are ephemeral and associated with a single VM.  Basically, they are never stored anywhere else and are not extractable—the software will never have access to those keys. 

“You can do whatever you need to do, but you will be in a cryptographically isolated space that no other strangers passing by can see.”

Memory controllers use the keys to quickly decrypt cache lines when you need to execute an instruction and then immediately encrypts them again. In the CPU itself, data is decrypted but it remains encrypted in memory. 

Confidential computing aims to mitigate gaps in data security

Nelly also shed some light on why confidential computing will continue to play a central role in the future of cloud computing. She pointed out that one of the biggest gaps companies are looking to cover is securing data when it is in use. 

Data that is encrypted on-premises or in cloud storage, but the biggest risk for companies is when they start working with that data. For instance, imagine you encrypted your data on-premises and only you hold the keys. You upload that data into Cloud Storage buckets—simple, safe, and secure. 

But now, you want to train machine learning models based on that data. When you upload it into your environment, it’s no longer protected. Specifically, data in reserved memory is not encrypted.We’re trying to ensure that your data is always protected in whatever state it exists, so fewer people have the opportunity to make mistakes or maliciously expose your data.

Top takeaways about confidential computing 

Throughout the conversation, Nelly also shared interesting points about the development and direction of confidential computing at Google Cloud. 

Here were our favorite takeaways from the podcast: 

We worked hard to make Google Cloud’s approach simple.
We’ve invested a lot of time and effort into investigating the possibilities (and limitations) of confidential computing to avoid introducing residual risks to our approach. For instance, the early introduction of hardware capable of confidential computing in the industry required IT teams to have the resources to rewrite or refactor their app, severely limiting their ability to adopt it within their organizations. 

With Confidential Computing, teams can encrypt data in use without making any code changes in their applications.  All Google Cloud workloads can run as Confidential VMs, enabled with a single checkbox, making the transition to confidential computing completely simple and seamless. 

“A lot of customers understand the values of confidential computing, but simply cannot support re-writing the entire application. It’s why Google Cloud, in particular, decided to take a different approach and use models that were incredibly easy to implement, ensuring that our customers would not have those barriers to cross.”

Confidential computing is for more than just fintech. 
There is, of course, a compelling use case for confidential computing at highly-regulated companies in financial, government, life sciences, and public sectors. However, Nelly shared that her team didn’t anticipate that even verticals without significant regulation or compliance requirements would be so interested in this technology, mostly to pre-empt privacy concerns. 

Many companies see confidential computing as a way to create cryptographic isolation in the public cloud, allowing them to further ease any user or client concerns about what they are doing to protect sensitive data. For instance, during COVID-19, there was an increase in small research organizations that wanted to collaborate across large datasets of sensitive data. 

“Prior to confidential computing, it wasn’t possible to collaborate because you needed the ability to share very sensitive data sets among multiple parties while ensuring none of them will have access to this data, but the results will benefit all of them—and us.”

An open community, working together will be key for the future. 
Nelly also shared that there are plans to extend memory protections beyond just CPUs to cover GPUs, TPUs, and FPGAs. Google Cloud is working with multiple industry vendors and companies to develop confidential computing solutions that will cover specific requirements and use cases.

Confidential computing will not be achieved by a single organization – it will require many people to come together. We are a member of the Confidential Computing Consortium, which aims to solve security for data in use and includes other vendors like Red Hat, Intel, IBM, and Microsoft. 

“Google alone would not be able to accomplish confidential computing. We need to ensure that all vendors, GPU, CPU, and all of them follow suit. Part of that trust model is that it’s third parties’ keys and hardware that we’re exposing to a customer.”

There are no magic bullets when it comes to security. 
Confidential computing is still an emerging, very new technology and unsurprisingly, there are a lot of questions about what it does and how it works. It’s important to remember that there is no such thing as the one-tool-fits-all-threats security solution. Instead, Nelly notes that confidential computing is yet another tool that can be added to your security arsenal. 

“No solution will ever be the magic bullet that will make everyone happy and secure, guaranteed. But confidential computing is an addition to our toolbox of defense against gaps we have to take super seriously and invest in solving.” 

Did you enjoy this blog post? To listen to the full conversation, head over to Episode One “Confidentially Speaking” of our Cloud Security Podcast, hosted by Anton Chuvakin (Head of Solutions Strategy) and Timothy Peacock (Product Manager). 

We also recommend checking out other episodes of the Cloud Security Podcast by Google for more interesting stories and insights about security in the cloud, from the cloud, and of course, what we’re doing at Google Cloud.

All over the world, businesses, schools and users depend on G Suite to help them stay connected and get work done. Google designs, builds, and operates our products on a secure foundation, aimed at thwarting attacks and providing the protections needed to keep you safe. G Suite and Google Meet are no exception.

Google Meet’s security controls are turned on by default, so that in most cases, organizations and users won’t have to do a thing to ensure the right protections are in place. Here, we’ll summarize the key capabilities of Google Meet that help protect you.

Proactive protections to combat abuse and block hijacking attempts

Google Meet employs an array of counter-abuse protections to keep your meetings safe. These include anti-hijacking measures for both web meetings and dial-ins. 

Google Meet makes it difficult to programatically brute force meeting IDs (this is when a malicious individual attempts to guess the ID of a meeting and make an unauthorized attempt to join it) by using codes that are 10 characters long, with 25 characters in the set. We limit the ability of external participants to join a meeting more than 15 minutes in advance, reducing the window in which a brute force attack can even be attempted. External participants cannot join meetings unless they’re on the calendar invite or have been invited by in-domain participants. Otherwise, they must request to join the meeting, and their request must be accepted by a member of the host organization. 

In addition, we’re rolling out several features to help schools keep meetings safe and improve the remote learning experiences for teachers and students, including:

• Only meeting creators and calendar owners can mute or remove other participants. This ensures that instructors can’t be removed or muted by student participants.
• Only meeting creators and calendar owners can approve requests to join made by external participants. This means that students can’t allow external participants to join via video, and that external participants can’t join before the instructor.
• Meeting participants can’t rejoin nicknamed meetings once the final participant has left. This means if the instructor is the last person to leave a nicknamed meeting, students can’t join later without the instructor present.

Secure deployment and access controls for admins and end-users

To limit the attack surface and eliminate the need to push out frequent security patches, Google Meet works entirely in your browser. This means we do not require or ask for any plugins or software to be installed if you use Chrome, Firefox, Safari, or Microsoft Edge. On mobile, we recommend that you install the Google Meet app. 

To help ensure that only authorized users administer and access Meet services, we support multiple 2-Step Verification options for accounts that are secure and convenient. These include hardware and phone-based security keys and Google prompt. Additionally, Google Meet users can enroll their account in our Advanced Protection Program (APP), which provides our strongest protections available against phishing and account hijacking and is specifically designed for the highest-risk accounts. 

For G Suite Enterprise and G Suite for Education customers, we offer Access Transparency, which logs any Google access to Google Meet recordings stored in Drive, along with the reason for the access (support team actions that you might have requested, for example). Customers can also use data regions functionality to store select/covered data of Google Meet recordings in specific regions (i.e. US or Europe). 

Secure, compliant, and reliable meeting infrastructure 

In Google Meet, all data is encrypted in transit by default between the client and Google for video meetings on a web browser, on the Android and iOS apps, and in meeting rooms with Google meeting room hardware. Meet adheres to IETF security standards for Datagram Transport Layer Security (DTLS) and Secure Real-time Transport Protocol (SRTP). For every person and for every meeting, Meet generates a unique encryption key, which only lives as long as the meeting, is never stored to disk, and is transmitted in an encrypted and secured RPC (remote procedure call) during the meeting setup.

Security is an integral part of all our operations at Google. Our team of full-time security and privacy professionals supports our software engineering and operations to ensure that security is always a part of how we build and run our services. All of our Google Cloud and G Suite customers benefit from these capabilities, including: 

• Secure-by-design infrastructure: Google Meet benefits from Google Cloud’s  defense-in-depth approach to security, which utilizes the built-in protections and global-private network that Google uses to secure your information and safeguard your privacy.
• Compliance certifications: Our Google Cloud products, including Google Meet, regularly undergo independent verification of their security, privacy, and compliance controls, including validation against standards such as SOC, ISO/IEC 27001/17/18, HITRUST, and FedRAMP. We support your compliance requirements around regulations such as GDPR and HIPAA, as well as COPPA and FERPA for education. 
• Incident management: We have a rigorous process for managing data and security incidents that specifies actions, escalations, mitigation, resolution, and notification of any potential incidents impacting customer data.
• Reliability: Google’s network is engineered to accommodate peak demand and handle future growth. Our network is resilient and engineered to accommodate the increased activity we’ve seen on Google Meet.
• Transparency: At Google Cloud, we’re clear about our commitments regarding customer data: we process customer data according to your instructions; we never use customer data for advertising purposes; and we publish the locations of our Google data centers, which are highly available, resilient, and secure.  

During COVID-19 and beyond, we will continue to protect Google Meet users and their data, and keep innovating with new features to make our tools helpful, secure, and safe.