SETH VARGO: In this episode of The Secret Manager video
series, we'll talk about the principle of least privilege
and how you can limit who can access your secrets.
Do you want to limit access to your secrets?
Stay tuned to find out how.
[MUSIC PLAYING]
The principle of least privilege says that an entity must only
be able to access the information or resources
necessary to perform its function.
In the context of Secret Manager,
this means humans and machines should only have access
to the secrets that are required to perform their function.
For example, a security engineer may have full control
to create and manage secrets, but an application developer
may only have permission to access a single secret.
But how do we accomplish this?
To tell us more about how to adopt the principle of least
privilege with Secret Manager, I think
we need to bring in an expert.
[MUSIC PLAYING]
Hey, Nick.
Thanks for joining us today.
NICK MUNARRIZ: Thanks, Seth.
Thank you so much for having me.
SETH VARGO: So Nick is a software engineer at Google
who works on Secret Manager.
Nick, earlier I was telling our viewers
about the principle of least privilege.
Could you tell us a little bit more
about how Secret Manager helps users adopt this principle?
NICK MUNARRIZ: Sure, Seth.
So on Google Cloud, most controls
are implemented using Cloud Identity and Access Management,
or IAM.
IAM provides very granular permissions
that are combined into roles.
Secret Manager currently offers five granular Cloud IAM roles.
First is the Secret Manager Admin IAM role,
which grants full access to administer Secret Manager
resources, including creating and deleting secrets.
Then the Secret Manager Viewer IAM role
grants permission to view the secret metadata
on Secret Manager resources, but it does not include the ability
to access secret payloads.
This is useful for auditing secrets
without actually seeing the payloads inside.
Then the Secret Manager Secret Accessor IAM role
grants the ability to access secret payloads,
but does not grant any administrative permissions.
This is useful for humans and applications that
need to access a secret, but don't need permissions
to manage those secrets.
The Secret Manager Version Manager IAM role
grants permission to manage versions of existing secrets,
but it does not include the ability
to access secret payloads or view or update
the metadata on any secrets themselves.
Finally, the Secret Manager Version Adder IAM role grants
permissions to add new versions to existing secrets,
but it does not include the ability
to access secret payloads or manage any versions or secrets.
This is useful for applications that might need
to perform simple rotations.
SETH VARGO: OK, so it sounds like Secret Manager has
this really nice separation of concerns between managing
secrets, auditing secrets, rotating secrets,
and accessing secrets.
So this will definitely help me adopt that principle
of least privilege.
But wouldn't granting someone Secret Manager Secret Accessor
permissions give them access to all
of the secrets in my project?
NICK MUNARRIZ: So that really depends on
where you grant that IAM permission.
Secret Manager's IAM roles can be applied globally
on a whole project or individually on just
a single secret.
If you grant an entity, like a user,
the Secret Manager Secret Accessor role
on the project, then that entity can access
all the secrets in the project.
But if you grant the Secret Manager Secret Accessor
to just an entity on a single secret,
then the entity will only be able to access that one secret.
SETH VARGO: OK, so it sounds like if I really
want to follow that principle of least privilege,
I should apply IAM roles at the most granular level.
NICK MUNARRIZ: That's right.
Since Cloud IAM's default policy is to deny,
applying the roles at the most granular level
is what really helps you achieve that principle of least
privilege.
SETH VARGO: OK, awesome.
But Google Cloud has these built-in roles,
like Project Editor and Project Owner.
How do those built-in roles map to these Secret Manager
permissions?
NICK MUNARRIZ: That's a really good question.
So project owners are kind of super users,
so they have full permissions to access and manage secrets.
Even if we remove this permission,
they could just grant it to themselves,
because they're also full IAM policy administrators.
SETH VARGO: OK, that makes sense.
We could take it away, but they could just
add it back themselves.
NICK MUNARRIZ: Yeah.
However, perhaps unlike other GCP services,
the ability to access secrets and the ability
to change IAM permissions on secrets
is not actually granted to the Project Editor role,
and that includes the default Compute Engine Service account.
This means the only Project Owners and entities
who are explicitly granted permissions can access secrets
in your project.
SETH VARGO: Awesome.
Thank you so much, Nick.
This really makes it clearer how Secret Manager
can help to adopt the principle of least privilege.
OK.
Let's take a look at how to practice
the principle of least privilege with Google Secret Manager.
I created a secret that contains my Twilio API key,
and I need to grant my Cloud Function permissions
to access that secret.
Now, I could go to the Cloud IAM settings
and grant my Cloud Function Service account
the Secret Manager Accessor permissions.
But as we learned from Nick, that isn't a best practice,
because that would allow my Cloud Function to access all
of the secrets in the project.
Instead, we want to follow the principle of least privilege
and grant access only to the secrets
that my Cloud Function needs.
To do this, I'll head over to the Secret Manager Console,
select my secret, expand the Info panel, click Add Member,
and grant my Cloud Function Service account permissions
to access the secret.
Here, I apply the IAM policy at the secret level,
meaning my Cloud Function won't have access
to the other secrets in my project.
I could also grant this permission using the gcloud
command line tool, or from the API using any of the Secret
Manager SDKs for .NET, Go, Java, Node, PHP, Python, and Ruby.
Google Secret Manager makes it easy to adopt and practice
the principle of least privilege.
That's all for this episode.
In the next episode, we'll talk about audit logging
and forensics with Secret Manager.
Be sure to like, subscribe, and click the bell
to get notifications about new episodes.
For even more tips and tricks with Google Secret Manager,
click Subscribe to Google Cloud Platform.
[MUSIC PLAYING]