Google Updates: Cloud HSM Beta, Binary Authorization for Kubernetes

Google is kicking off its week with a few cloud security updates: the beta release of Cloud HSM, a managed cloud-hosted hardware security module (HSM) service, and the introduction of binary authorization for its Google Kubernetes Engine to secure production infrastructure.

The idea behind Cloud HSM is to give Google Cloud Platform (GCP) users another option to protect their sensitive data and meet compliance requirements, explains product manager Il-Sung Lee in a blog post. Users can host encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 certified HSMs to protect workloads without managing an HSM cluster.

HSM clusters require management, scaling, and upgrades, contributing to operational overhead. The Cloud HSM service is managed via regular Cloud KMS APIs, and it handles patching, scaling, and clustering without the added downtime, Lee writes.

Because the service is integrated with Google Cloud key management service (KMS), users can secure data in Google Compute Engine, BigQuery, Google Cloud Storage, DataProc, and other encryption key-enabled services with a hardware-protected key. On the compliance side, users will be able to verify cryptographic keys were created within the hardware boundary.

In addition to the beta release of Cloud HSM, Google is also announcing asymmetric key support for both Cloud HSM and Cloud KMS. Now, in addition to creating symmetric key encryption using AES-256 keys, users can create different types of asymmetric keys for signing processes or decryption. Lee reports RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 keys will be available for signing; RSA 2048, 3072, and 4096 keys can decrypt blocks of data.

Binary Authorization for Google Kubernetes Engine
Google is also rolling out a beta release of Binary Authorization for its Kubernetes Engine, reports product manager Jianing Sandra Guo, so users in enterprise security and DevOps can trust content running on their production infrastructure.

Binary Authorization is a container security feature baked into the Kubernetes Engine deployment API, Guo writes in a blog post on the news. Its purpose is to provide a "policy enforcement chokepoint" so only signed and authorized images are used in the environment.

It's especially handy in the age of containerized microservices, she explains. Many businesses run hundreds to thousands of jobs in production, often containing valuable data. While they could use identity-based control to restrict which people can deploy, this strategy relies on human operational knowledge that can't be scaled for businesses with automated build and release structures, running hundreds of deployments each day across dozens of teams.

Binary Authorization runs on three principles, Guo says: establishing preventative security by only running trusted code, simplifying governance with a single path for code to move from development to production, and using open source to keep CI/CD tools interoperable. She also adds the feature is based on internal Google tech the company uses to protect deployments.

How it works: Binary Authorization integrates with desired CI/CD stages to produce signatures as images pass through, and it blocks those that don't meet the organization's criteria. On top of signature-based verification, the tool also lets users whitelist images using name patterns.

Unpatched third-party software is a common source of production vulnerability, Guo explains. Whitelisting lets users specify a repository, path, or set of images that are allowed to deploy, limiting the opportunities for compromise via third-party images. This option provides a centralized list of third-party images so users can identify which are vulnerable.

If you want to review failed deployment attempts, Binary Authorization also integrates with Cloud Audit Logging to record failures for further analysis, Guo adds.

With today's beta release, users can create Kubernetes Engine clusters with Binary Authorization to access deploy-time policy controls. Users can set "attestors," or authorities to verify images. Deployment policies can be set at both project and cluster levels for different levels of control — for example, if you want separate policies for dev and compliance clusters.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early bird rate ends August 31. Click for more info.