MARTIN OMANDER: Hi, Xiaowen.
XIAOWEN XIN: Hi, Martin.
MARTIN OMANDER: You're a product manager focusing
on serverless security, right?
XIAOWEN XIN: Yes.
MARTIN OMANDER: Great, because I have some developer
questions for you about software supply chain security.
XIAOWEN XIN: Great to hear, and it's one of my favorite topics.
[MUSIC PLAYING]
MARTIN OMANDER: So Xiaowen, I hear
from developers who are worried that they
might be vulnerable to software supply chain attacks.
In the recent SolarWinds attack, the attacker
compromised the build platform, and in the Codecov attack,
the attacker uploaded an artifact that was not
built by the CI/CD system.
How can I protect my system?
XIAOWEN XIN: Well, Martin, it's a complex problem,
and we want to help developers navigate it.
One thing you can do today is to use Binary Authorization
to make sure that only approved builds can
get deployed to Google Kubernetes Engine or Cloud
Run in your project.
MARTIN OMANDER: Great, because I have a Cloud Run service
here that I'd like to secure so that no one can
bypass my CI/CD pipeline.
Can you walk me through it?
XIAOWEN XIN: Sure.
And I know that you use Cloud Build for your CI/CD pipeline,
so let's first enable Binary Authorization on your project.
You go into the Cloud Console and click the hamburger menu.
Then select Security and Binary Authorization.
Click Enable to turn on the API.
Now let's deploy your Cloud Run service again.
MARTIN OMANDER: Oh, OK.
Doing so now.
This will also take a minute.
XIAOWEN XIN: And now that it's been deployed,
let's go back to Binary Authorization and click
Attestors.
You will see that an attestor has been automatically created.
From now on, this attestor will cryptographically sign every
build done in Cloud Build so we know where it comes from.
The signed attestation includes provenance information,
such as the source code that it was built from
and the commands used to build it.
MARTIN OMANDER: Ah.
And what will we do with this attestor?
XIAOWEN XIN: Good question.
If we go back to the Policy tab, we
see that there is a default policy here
that allows all images to be deployed.
Let's update this policy to require
that all builds must be signed by that attestor
before they can be deployed.
And in other words, all builds must come from your Cloud Build
pipeline.
Click Edit Policy, select Require Attestations,
click Add Attestors, and in the Attestor name box,
you can select built-by-cloud-build
in the dropdown.
Then click to add this attestor.
Click Save Policy.
Now let's review the policy again and confirm
that we're requiring images to be approved by this attestor,
meaning that all images must come from Cloud Build.
MARTIN OMANDER: Ah, OK.
Is this policy now being enforced on my service?
XIAOWEN XIN: Not just yet.
Right now, any authenticated user with the right IAM
permissions can still deploy images and containers,
regardless of where they were built.
MARTIN OMANDER: How do I lock that down?
XIAOWEN XIN: Let's go back to your Cloud Run service
and click the Details tab.
Where it says Binary Authorization, click Enable.
Now the policy is guarding this service
from containers built outside your project.
MARTIN OMANDER: I feel better now.
If I tried to deploy a container that
wasn't built by Cloud Build in this project,
will the system refuse to deploy it?
XIAOWEN XIN: Yeah.
Try it out.
MARTIN OMANDER: OK, I will go here to Cloud Run.
I happen to know that Google provides
a sample container for testing.
I don't know how that container was built,
but I do know that it wasn't built
by Cloud Build in my project.
Let's try to deploy it.
XIAOWEN XIN: And it looks like the deployment failed.
MARTIN OMANDER: Perfect, just what I want.
Containers built in my project can be deployed,
but not containers built by others.
Now what if I forget to turn on Binary
Authorization for my service?
Is there a way to make sure that Binary Authorization protects
all the services in my project?
XIAOWEN XIN: Yes, glad you asked.
We support an organization policy
for Binary Authorization.
Let's go turn that on.
Click the hamburger menu, then IAM & Admin, then Organization
Policies.
Select Allowed Binary Authorization
Policies for Cloud Run.
Then click Edit.
And let's customize this policy and add a rule that
allows the default policy.
Click Done, then Save.
This will take effect within a few minutes.
MARTIN OMANDER: Oh, that was also easy.
XIAOWEN XIN: Yeah.
And this protects against attackers,
but it also helps you ensure that your builds are consistent
and that no one in your organization
accidentally deploys containers built on their laptops
or on other places.
MARTIN OMANDER: I like that.
Now we've plugged one hole here, and viewers
should be able to try this at home pretty easily.
If they set this up today, their projects
would be a little bit safer.
But Xiaowen, what is the bigger picture here?
How can an organization get up to speed on software supply
chain security overall?
XIAOWEN XIN: Great question.
Google and the broader community have
launched a website called Supply Chain
Levels for Software Artifacts.
MARTIN OMANDER: Oh, that's a mouthful.
XIAOWEN XIN: It's abbreviated to SLSA,
which is pronounced salsa, and the website is at slsa.dev.
On that website, you can learn about a framework
for assessing the security of your supply chain
and gradually increasing that security level.
We welcome everyone to work with us
to level up the supply chain security for the whole software
ecosystem.
And in fact, what we did together today
with Cloud Build and Binary Authorization already
meets quite a few of those requirements.
MARTIN OMANDER: Excellent.
Thank you for joining me, Xiaowen.
XIAOWEN XIN: You're welcome.
MARTIN OMANDER: And thank you, everyone, for watching.
If you have questions for Xiaowen
or me about Binary Authorization or feedback on this episode,
post them in the comments.
Also, please let us know what other serverless topics you'd
like to hear about on the show.
Bye for now.
[MUSIC PLAYING]