At Google Cloud, we believe in making it simple and secure to consume services whether they’re from Google, a third party or customer-owned. With Private Service Connect, we have adopted a service-centric approach to our network that abstracts the underlying networking infrastructure. And today, we are announcing Private Service Connect is generally available in all Google Cloud regions.

Private Service Connect allows you to create private and secure connections from your cloud networks to services like Cloud Storage or Cloud Bigtable and third-party services like Elastic, MongoDB or Snowflake. It creates service endpoints in your VPCs that provide private connectivity and policy enforcement, allowing you to easily connect to services across different networks and organizations.

Customers told us they want to consume services faster while making sure that the connectivity is private and secure. In the past, achieving this was a challenge: networking teams had to negotiate IP address blocks, mutually agree on policies and coordinate as applications evolved to newer versions. With Private Service Connect, you can delegate the consumption and delivery of services to different teams without having to coordinate between teams.

How it works

Private Service Connect makes it easy to consume services by leveraging service endpoints that are locally managed. The services can be in different projects or managed by different organizations. Access to the service is controlled by strict governance and IAM policies. Application teams and developers can focus on delivering their services easily by exposing their ‘service attachment’. No more worrying about networking constructs—Private Service Connect takes care of connecting to the service on the Google backbone for them.  

Benefits to our partners

Being able to consume services from a variety of software vendors and service providers makes it possible for enterprises to innovate faster. For that, developers need to be able to compose services from third-party vendors, Google managed services, as well as their own services. To help, third-party partners can use Private Service Connect to deliver multi-tenant services securely and at massive scale, and make the connectivity to their services appear as if they are running on the enterprises’ network. Private Service Connect will also integrate with Service Directory to register many producer services, making service consumption even simpler. 

“In today’s environment, where seamless access to real-time market information and the ability to handle increasingly vast volumes of data is essential, our clients are demanding native connectivity in the cloud. Google’s Private Service Connect offers the performance and reliability required by the types of mission critical apps that rely on Bloomberg’s tick for tick market data feed, B-PIPE.” —Cory Albert, Global Head of Cloud Strategy, Enterprise Data at Bloomberg 

“One of the key goals for Elastic on Google Cloud is to monitor and protect our customers’ data. Google Cloud’s Private Service Connect with Elastic Cloud furthers our commitment to our customers that together we make it quick, easy and secure to gain insights and intelligence from their data.” —Uri Cohen, Product Lead for Elastic Cloud

“MongoDB’s partnership with Google is an integral part of our strategy to support modern apps and mission-critical databases and to become a cloud data company. Private Service Connect allows our customers to connect to MongoDB Atlas on Google Cloud seamlessly and securely and we’re excited for customers to have this additional and important capability.”—Andrew Davidson, VP of Cloud Product, MongoDB

Check out the Google Cloud Console to try it today.

Our Cloud Data Loss Prevention (Cloud DLP) discovery service can monitor and profile your data warehouse to bring awareness of where sensitive data is stored and processed. Profiling is also useful for confirming that data is not being stored and processed where you don’t want it. 

But how can you make use of this intelligence within your existing security and governance workflows so you can reduce risk? Starting today, we have integrated Cloud DLP’s sensitive-data discovery service with Security Command Center, our platform-native security and risk management solution. By bringing together sensitive data intelligence with your security controls, security teams can identify and act quickly on the vulnerabilities and help address threats that matter for your organization.

Data sensitivity and risk prioritization

Not all security threats, vulnerabilities, and misconfigurations generate an equal degree of risk. Some affect only test data or development environments. But others can place your organization’s sensitive information at risk of exposure or misuse. Understanding what to prioritize is often a big challenge for security professionals.

When this awareness is fed into Security Command Center, it allows your team to prioritize the Security Command Center findings that are driving greater security and compliance risk, and to help make informed decisions as to how to address those issues.

Understanding BigQuery data exfiltration threats

Security Command Center’s threat detection capability can analyze access and copy behavior of BigQuery data to help detect potential risk of exfiltration. With Cloud DLP intelligence on where sensitive data lives in BigQuery tables and datasets, you can now focus and prioritize on the exfiltration findings tied to your sensitive assets.

Remediation and data security posture management

The intelligence from Cloud DLP’s sensitive-data discovery service helps you take a data-first approach to securing your assets.  Use insights like Cloud DLP’s predicted infoType to apply column-level, fine-grained access or dynamic masking policies and consider de-identification to further help reduce the risk of data use operations and improve your overall security, privacy, and compliance posture.

Get started

To get started with richer sensitive data intelligence, enable the connection between Cloud DLP’s discovery service and Security Command Center.  There is no additional cost to enable the integration for users of both products.  

As soon as it’s enabled, you can begin to use your sensitive data intelligence to supercharge your security and support your compliance teams’ work.

Read more about how the sensitive data discovery service can meet your organization’s needs, and how you can get started managing your security posture with Security Command Center.

Prior to joining Google Cloud, I spent 20 years in the public sector serving in various security roles, most recently as the head of the cybersecurity division at the newly established Cybersecurity and Infrastructure Security Agency (CISA). I was responsible for delivering services and capabilities to about 100 civilian agencies, as well as our critical infrastructure for state and local partners across the country.

Throughout my time serving in the U.S. government, I spent a great deal of energy working to keep bad actors out of our systems. What I eventually realized was that we were at a disadvantage. We didn’t just have legacy systems to deal with; we also had a legacy mindset. Our policies and capabilities were overly reliant on a perimeter-based approach to defense and introduced layers of friction with tools like VPNs, which inhibited productivity and increased frustration.

I spent the last few years of my time in the government doing my best to modernize this approach to security and supporting the many people who shared this vision. While most of them are still there, doing excellent work, repeated cybersecurity breaches of U.S. government systems have interrupted vital work and cost taxpayers billions of dollars. The SolarWinds breach in 2020, for example, may have cost governments and businesses more than $100 billion and the loss of vital national security information. Yet many government agencies continue to rely on the same legacy productivity software.

Today, a new survey conducted by Public Opinion Strategies and commissioned by Google Cloud shows that many government workers echo these concerns. The survey—which polled 2,600 working Americans, includes 600 workers from the D.C. metro area and 338 workers employed by federal, state, or local governments across the country—found that the majority of government employees surveyed reported being “very” concerned about cyberattacks striking their employers in the coming years. And nearly one-third of surveyed government employees in the D.C. metro area say they have experienced a disruption at work because of a cyberattack.

Results from the survey also showed a lack of satisfaction with legacy software, with more than 50% of government workers nationally responding that there are other products and services that could help them do their jobs better.

These new findings not only speak to the challenges our government employees face, but also outline an opportunity for improved innovation and security that can help government employees better achieve their missions.

Concerns about cybersecurity

The majority of respondents said they believed it was likely that the federal government would be the victim of a cyberattack in the next few years. This percentage was even higher in the D.C. metro area and among government employees, with 40% of government workers living in metro D.C. saying it was “very likely.”

Respondents in all groups—national, D.C. metro, and government employees—were more likely to be concerned about cyberattacks as the perceived threat moved closer to home. For example, 80% of those surveyed said that recent attacks have them concerned about their personal data and privacy, and that of their family members. And for those in the D.C. area or in government jobs, the numbers were consistently higher than the national average.

One likely reason for such broad concern about cyberattacks is that many respondents reported experiencing a cyberattack at work. And while more than one-in-ten workers nationally have experienced disruptions from a cyberattack, the number increased to nearly one-in-three for D.C.-based government employees—nearly three times higher than the national average.

The problem with IT ‘monoculture’

According to survey respondents, 84% of D.C. metro government employees primarily use Microsoft products at work, including Word, Outlook, Teams, and OneDrive. This is confirmed by another recent study by Omdia that found 85% of government employees use Microsoft productivity software, far and away the largest IT productivity vendor by market share.

This reliance on a single software suite might suggest that these products are safe and secure, but the Public Opinion Strategies survey found that more than half of all respondents said that the government’s reliance on these Microsoft products actually made the federal government more vulnerable to hacking or cyberattacks.

Given these vulnerabilities, why does government IT continue to rely on the same set of productivity tools in the workplace? The reason, according to survey respondents, has more to do with inertia than innovation. When asked why their employers used Microsoft services, around half said that the reason their employer continues to choose legacy, incumbent vendors was more about not wanting to change than wanting the most effective tool for the job.

Choice and shadow IT

Coupled with these concerns about vulnerabilities comes a noted sentiment among those surveyed that their current IT solutions are not best for their needs. About half of those surveyed who primarily use Microsoft at work said that they would prefer to have a choice to use products and services from other companies. And among those who use Microsoft at work, 43% believe there are other products and services that would allow them to do their job better.

This may be leading workers to adopt “shadow IT,” or using products and services that are not officially approved or endorsed by their IT departments. In fact, the Public Opinion Strategies survey found that 35% of D.C. metro government workers have used shadow IT to get their jobs done. And among workers aged 20 to 34, that number jumps to 41%.

Rethinking IT purchasing priorities

With so many survey respondents reporting that they are dissatisfied with their legacy IT solutions, it may be time for the government to rethink its approach to procurement. In a separate research survey from Omdia in December 2021, 250 people responsible for technology purchasing decisions in the U.S. federal, state, and local governments said that government technology and procurement practices often are more about making things easier for IT vs. choosing what employees feel would be the best solution. In fact, only 27% of officials surveyed in that research cited “user demand” as a factor affecting their purchasing decisions.

As governments work to meet the demands and preferences of their constituents—and their employees—it’s clear that there’s an overreliance on legacy solutions, despite a track record of cybersecurity vulnerabilities and poor user perception.

At Google Cloud, we believe it’s time for more diversity and choice in the tools available for our civil servants across the nation—70% of whom use Gmail outside of work, according to our survey. Government workers have the right to benefit from the same flexible, secure-by-design tools at the office that they use in their personal lives. You can learn more about Google Workspace for Government here.

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.