SETH VARGO: In this episode of the Secret Manager video
series, we'll talk about how Secret Manager automatically
versions your secret payloads.
Should you pin your applications to a specific version
or always use latest?
Stay tuned to find out.
[FUNK MUSIC PLAYING]
In Secret Manager, a secret is a logical collection
of secret versions.
Versioning is a core tenant of reliable systems
to support gradual rollout, emergency rollback,
and auditing.
Secret Manager automatically versions secret data
using secret versions, and most operations
like access, destroy, disable, and enable all
take place on a secret version.
While the parent secret holds metadata information,
like name and replication policy,
the secret version stores the actual secret payload,
your secret data.
Once a secret version is created,
its payload is immutable.
That means version 42 of a secret
will always contain the same payload.
When a new secret version is added,
it automatically becomes the latest version.
So should your applications pin to a specific version,
or should they just use latest?
To answer that question, I think we need to bring in an expert.
[FUNK MUSIC PLAYING]
Hey, Rachana.
Thanks for joining us today.
RACHANA LINGUTLA: Thanks, Seth.
Thank you for having me.
SETH VARGO: So Rachana is a software engineer who
works on Google Secret Manager.
OK, Rachana.
Earlier, I was telling our viewers
about secret versioning and the latest alias.
When should we pin our applications
to a specific version, and when would we use this latest alias?
RACHANA LINGUTLA: Sure, Seth.
To help answer that question, let's look
at a hypothetical scenario.
Suppose we have an application that
uses an API key to communicate with a third-party service.
If the application was using the latest alias,
Secret Manager would always return the most recent value,
regardless of whether that value was ready to be consumed.
If the application was pinned to a specific version,
Secret Manager would return the pinned version,
even if a newer version exists.
SETH VARGO: OK, but then if I pay my application
to a specific secret version, how
would I update the secret used by that application?
Do I have to package and rebundle and redeploy
my whole application?
RACHANA LINGUTLA: Actually, yes.
At Google, we believe secrets are configuration,
and configuration should be versioned
with the deployable artifact.
SETH VARGO: OK.
That kind of makes sense.
So that way if there's a problem or a bug,
I can easily rollback, and if I rollback,
my configuration would include the old secret version.
So my application is then bundled
in a known working version, right?
RACHANA LINGUTLA: Exactly.
SETH VARGO: OK.
OK, so it seems like the latest alias is not
good for production.
But it'd be really useful when I'm
doing rapid iteration in my development or staging
environments.
Is that right?
RACHANA LINGUTLA: Yes, that's right, Seth.
SETH VARGO: Awesome.
Thanks, Rachana.
OK.
Let's look at a Google Cloud function
that accesses a secret using the Secret Manager API.
While iterating in my local development environment,
I'd instruct my Cloud Function to access the secret using
the latest alias.
But when I'm ready to move to production,
I would pin my deployment to a specific secret version.
Secret Manager's first-class versioning
helps you follow a DevOps best practice
of reproducible deployments, while the latest alias provides
a convenient method for rapidly iterating during development.
That's all for this episode.
In the next episode, we'll talk about the principle
of least privilege and how Secret Manager can
help you get there.
Be sure to like, subscribe, and click the bell
to get notifications about new episodes.
For more tips and tricks with Google's Secret Manager,
subscribe to Google Cloud platform.
[FUNK MUSIC PLAYING]