[MUSIC PLAYING]
ANOOSH SABOORI: Welcome to the Google Cloud Security Showcase,
a special web series where we'll focus on security use cases
that customers can solve with Google Cloud.
My name is Anoosh Saboori, and I'm a Product Manager
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers--
how to use Certificate Authority Service
to create private certificates for DevOps.
Enterprise organizations are frequently
surprised at the extent of extra work
they must do, having bought CA technology,
to bridge the gap between technology
and their organizational and business goals.
A globally scalable CA is often hard to deploy and manage,
because it requires deep expertise
that many organizations do not have.
Also, traditional CA solutions are
not well-suited for new cases, such as microservices
and DevOps, because they are often inflexible,
don't scale well, and are not integrated
into the deployment and access control
infrastructures commonly used within the Cloud Services.
Lastly, traditional CAs are expensive,
with high CapEx and infrastructure, hardware
and software licensing, in addition
to expensive ongoing costs.
With Google Cloud's CA service, you
could solve these challenges with a service that
simplifies deployment and management of private CAs,
which also automates time-consuming, risky,
and error-prone infrastructure tasks.
More specifically, you can create a private CA in minutes,
versus weeks that it takes to deploy a traditional CA,
and focus on higher value projects
by offloading time-consuming tasks like hyper provisioning,
infrastructure security, software deployment,
high availability configuration, disaster recovery, backups,
and more to the cloud.
In addition to deployment and management simplification,
CA service can be tailored to your needs.
You can configure custom CAs and certificates,
automate common tasks with APIs, and integrate
with your existing systems.
And finally, you can have peace of mind knowing
that your CA service is highly available, scalable,
backed by an SLA, auditable, and ready to help you achieve
compliance with advanced hardware and software security
controls.
Next, we show how to get started with CA service
using the Cloud Console.
First, you would need to enable CA service
by navigating to Certificate Authority Service tab
under Security.
I have already done that for this demo.
After that, you can start creating a CA
by clicking on Create CA.
Start by deciding whether this is a root or a subordinate CA.
Note that you can configure the subordinate CA to chain
up to the root that is hosted outside Google Cloud platform.
Let's pick Root CA.
You can customize how long the certificate is valid for.
Next is to decide on CA tier.
DevOps optimizes for a high volume,
short-lived certificates, like those used in microservices
valid for a few hours or days.
Enterprise optimizes for lower volume
but longer-lived certificates, like laptop certificates
are valid for months or years.
We pick Enterprise for the root.
We can also specify the region the CA runs in.
Obviously, it's better to pick a region that
is closer to where your workload would run.
To simplify going through these steps,
we also provide pre-filled CA configurations
for commonly used sets, for example,
for server authentication.
The next step is to contribute the CA subject name.
And let's leave Google Cloud as the organization name, Security
and Privacy as the organization unit,
and perhaps, as the common name for the CA,
we can pick a name like GCP Test Root CA.
As you notice, we picked the same name for Pool ID.
A CA pool is a collection of multiple CAs
with a common certificate issuance policy and IEM policy.
CA pools provide the ability to rotate trust chains
without any outages or downtime for their payloads.
It also helps increasing the maximum throughput of the CAs
by load balancing incoming requests across the CAs
belonging to the same pool.
When creating a new CA, we basically
create a new pool for it by default.
You can add CAs to an existing CA pool using our command line
tools or APIs.
And here is the Resource ID belonging to the CA.
Click on Next.
Next step is to configure the CA key size and algorithm.
You can choose between a Google managed key, which
will be hosted on HSM, or a customer managed key,
where you can configure an existing Cloud KMS or HSM
key to be used by CA service.
Note that if you use Google managed keys,
Google will take care of key lifecycle management,
including deleting the keys when the CA is deleted.
And there will be no extra charge for the key usage.
Let's pick a 4K RSA key for the root.
The next step is to configure the Certificate Revocation
List, or CRL, location.
First, you will need to enable CRL distribution.
By default, this option is turned off,
since you can rely on short-lived certificates
to remediate the risk.
CRLs will be hosted on GCS buckets.
Like CA keys, we offer two options
for managing the GCS bucket--
Google-managed GCS bucket, where Google
takes care of GCS bucket lifecycle management, including
deleting it when the CA is deleted;
and customer managed GCS bucket, where you
can bring your own GCS bucket.
There will be no extra charge when using Google
managed GCS bucket.
Let's pick that.
Next, you can add a label to enable
easy grouping of your Cloud resources, as such.
Last step is to review this summary and create the CA.
See, it's all the information you provided.
And click on Create.
You can see the newly created CA in this page.
Just like that, we created a Cloud-based CA
using Cloud HSM in a matter of seconds.
In addition to Cloud Console, you
can manage, automate, and integrate private CAs with APIs
and GCloud command line as well.
Now that the CA is created, let's
see how we can obtain a certificate from it.
You can leverage simple descriptive RESTful APIs
to acquire and manage certificates
without being an expert.
You can also use the console.
Let's see how that looks in a Cloud Console experience.
Start by navigating to Request a Certificate.
Here, you have two options.
You can either provide a certificate signing request,
or use the in-browser memory to create the public private key
and request a certificate for that pair.
You also see a notion of certificate templates here.
Certificate templates can be used
to enable consistency across certificates issued
from different [? samples. ?] You can use a certificate
template to restrict the kinds of certificate
that different individuals can issue and restrict
different X.509 values in the certificate.
Let's pick the simple way, provide a detail.
Here, you can customize how long the search is valid for,
pick your name, add a domain name for the certificate-- say,
foo.com-- decide on the extended key usage extension,
decide on the algorithm and key size
to be used to generate the public/private key.
And again, these keys are generated in the context
of browser that you run in.
And Google will never see these private keys.
And just like that, you have a certificate and a private key
to download, which you can start using in your environment.
As you can see, the issued certificate
shows up under Private Certificate Manager tab.
We have information about who issued the cert
and when the cert was issued and when it's expired.
From the same console, you can take actions
like revoking the certificate or download this certificate
full chain.
We also have a tab for Overview, which gives you
a summary of CAs in that environment, including
any potential access issues to the key material,
the expiration for the CAs, and number of certificates
issued by those CAs.
So this gives you a holistic view
of the operation of your environment.
As you can see, it is now much easier and faster
to create and manage private CAs with our new service
and also obtaining certificates from that service.
Thank you for watching.
Please visit cloud.google.com/security
to learn more.
[MUSIC PLAYING]