SETH VARGO: In this episode of the Secret Manager video
series, we'll talk about global secret names
and regional replication policies.
Should you choose user-managed or automatic?
Stay tuned to find out.
[MUSIC PLAYING]
In Secret Manager, secret names are project global resources.
This is because secrets rarely differ across cloud regions.
As a concrete example, your Twilio or Twitter API key
doesn't change when you move your application from US-EAST1
to EUROPE-WEST4.
This is different from other Google Cloud resources, which
have a tighter coupling to a particular region or geography.
For example, in Google Compute Engine.
Virtual machine instances are bound and referenced
by the zone in which they're created.
Even though the secret's name is a project global resource,
the secret's payload is still stored regionally.
This means that a secret is globally
addressable by a single name, but
the underlying secret material is still
stored in particular regions.
Payload storage may be an important concern
for regulated customers or for customers
that have strict requirements over where
their data is stored--
like banking, fintech, or health care.
Other customers may prefer to have their data stored
closer to where they plan to access it, to minimize latency.
But how do you choose the regions in which
the secret payloads are stored?
Google Secret Manager features replication policies,
which give you the freedom to choose how and where
your secret payload is stored.
To tell us a little bit more about replication policies,
I think we need to bring in an expert.
[MUSIC PLAYING]
Hey, Colin.
Thanks for joining us today.
COLIN MAN: Hey, Seth.
Thanks for having me.
SETH VARGO: So Colin is a software engineer working
on Google Secret Manager.
OK, Colin.
Earlier, I was telling our viewers
about data storage and regionalization of Secrets.
Could you tell us a little bit more
about Secret Manager's replication policies?
COLIN MAN: Sure, Seth.
Replication policies offer control
over where your secret payloads are stored.
Some enterprises want full control
over the regions in which their secrets are stored,
while others don't have a preference.
Secret Manager addresses both of these customer requirements
and preferences with the replication policies.
If you don't care about where your payload is stored,
you should choose an automatic replication policy.
With automatic replication, Google Cloud
chooses the best regions to replicate your secret payload.
This strategy also offers the highest availability guarantees
for accessing and creating secrets.
SETH VARGO: OK, Colin, but which regions
does Secret Manager pick if I choose automatic replication?
COLIN MAN: That's explicitly unspecified behavior, Seth.
You should interpret automatic as I don't care.
SETH VARGO: But what if I do care?
What if I care too much about where
my secret payload is stored?
COLIN MAN: Then, you should choose user-managed replication
policies.
With user-managed replication, you choose one or more regions
to which to replicate your secret payloads.
SETH VARGO: Yeah, but then I'm going
to have to run some Cloud Function that replicates
my secret payload and I have to deal
with all the monitoring and the alerting and the paging
and the 3:00 AM--
COLIN MAN: No, actually--
SETH VARGO: --and it's just like--
COLIN MAN: Actually, you won't.
User-managed is more like user selected.
You pick the regions and Secret Manager automatically
handles the replication.
SETH VARGO: Oh, that's super cool.
I'm just going to replicate my secret payload into all the
available Google Cloud regions.
That's going to give me the most availability and the lowest
latency.
Thanks, Colin.
COLIN MAN: Well, I'd be careful with that.
SETH VARGO: What?
Why is that?
COLIN MAN: While replicating a secret payload to every region
improves the reliability of accessing a secret,
it may decrease the reliability of adding a secret version.
SETH VARGO: Ah.
OK, that makes sense.
Well, it-- wait.
No, that-- that doesn't make sense.
Why is that?
COLIN MAN: Well, in order to add a secret version,
all of the regions you select must be operational.
If you choose a lot of regions and any single one
of those regions is down, you can no longer
add a new secret version.
SETH VARGO: I see.
So depending on my application, I
can choose to balance my read availability
and my write availability accordingly.
COLIN MAN: Exactly.
SETH VARGO: So how many regions should I choose, Colin?
COLIN MAN: Well, as you mentioned,
it's heavily dependent on the application.
As a general recommendation, you should choose at least two
but no more than five regions.
SETH VARGO: Awesome.
Thanks, Colin.
COLIN MAN: No problem, Seth.
SETH VARGO: OK.
Let's look at how we set a secret's replication policy
from the Google Cloud console.
First, we choose the secret's name, initial payload,
and then, we have the option of selecting regionalization.
Notice that the default behavior is automatic, since that's
what most customers will choose.
If I want to select specific regions, I can check the box
and pick the replicated regions from the menu.
I can also set replication policies from
the command-line-- using the gcloud tool--
or from the API--
using any of the Secret Manager SDKs for .NET, Go, Java, PHP,
Node, Python, and Ruby.
Google Secret Manager's flexible replication policies
give you choice over where your secrets are stored.
If you don't have specific regionalization requirements,
choose the automatic replication policy.
But if you do have specific regionalization requirements,
pick the user-managed replication policy
with specific regions.
For even more tips and tricks with Google Secret Manager,
subscribe to Google Cloud platform.
[MUSIC PLAYING]