MARTIN OMANDER: Hi, Xiaowen.
XIAOWEN XIN: Hi, Martin.
MARTIN OMANDER: Many of my Cloud-run apps
are for company internal users only.
And I wish there was an easier way to set that up.
XIAOWEN XIN: And how do you handle that today?
MARTIN OMANDER: Well, my users must VPN to the Virtual Private
Cloud first.
And then they can log in again to the applications.
And there's no central place to manage fine-grained access.
XIAOWEN XIN: Ah.
There is a better way, with Identity-Aware Proxy.
By using a zero-trust approach, there's no need for a VPN.
It also gives you centralized access control
across all of your applications.
[MUSIC PLAYING]
MARTIN OMANDER: Xiaowen, you are a product manager
for Cloud Run, focusing on networking and security, right?
XIAOWEN XIN: Yes.
And as a product manager, I hear from customers
who want to simplify authentication for company
internal Cloud Run applications.
MARTIN OMANDER: And that's where Identity-Aware Proxy comes in?
XIAOWEN XIN: That's right.
Identity-Aware Proxy, or IAP for short,
is a product in Google Cloud that you can put
in front of other applications.
It only lets in users that are on its approved list.
MARTIN OMANDER: Sounds good.
XIAOWEN XIN: And that means security admins
can control access to apps in one centralized place.
And also, they don't need to maintain a VPN anymore.
And app developers can focus more on business logic
as IAP handles authentication.
The code simply needs to check a header
and each incoming request.
This means fewer lines of code and a lower chance of errors
due to bugs or oversights.
MARTIN OMANDER: Right.
I've used IAP to manage access to my web apps on App Engine.
XIAOWEN XIN: Yes.
And we recently launched Cloud Run integration
to general availability.
So now, IAP can control access to your Cloud Run applications
as well as App Engine, Compute Engine, and Kubernetes Engine.
MARTIN OMANDER: Nice.
Can you show us how it works?
XIAOWEN XIN: Sure.
Here is the centralized control panel
where a security admin can manage access provided by IAP.
You can see all the applications in this project here.
This is an ERP system that runs on a Kubernetes cluster.
This is a Cloud Run service that runs my financials.
And this is an intranet front end
that runs on a virtual machine.
And this is a public website that's hosted on App Engine.
MARTIN OMANDER: And the public website is open to the public?
XIAOWEN XIN: Yes, it is.
I turned off IAP for it.
All other applications are locked down.
My internet website is open to everyone,
which is a group I created that includes everyone
with an email in my domain.
MARTIN OMANDER: But the financial system
should perhaps only be open to the finance team?
XIAOWEN XIN: Yes, exactly.
If I click the application, go to the info panel,
we see that only the finance team has access.
MARTIN OMANDER: Right.
And when I try to hit your finance application,
I get this login prompt.
And you gave me an account in your domain
before, martin@xiaowen.com.
So I'll try to log in with that account.
Ah, and access is denied.
XIAOWEN XIN: Great.
Now, let's say that you need temporary access
for a few weeks.
I can grant you access directly from the info panel.
So click on Add Principal, and enter your account,
and grant you the IAP-secured Web App user role.
MARTIN OMANDER: So you can grant access
to groups or to individual users?
XIAOWEN XIN: That's right.
MARTIN OMANDER: All right.
Let's give the permissions a minute to propagate.
And I'll go to your finance application again.
And now I have access.
Oh, it shows my account name there.
How does the app know?
XIAOWEN XIN: Great question.
What's happening here is that IAP adds some headers
to the HTTP requests.
This is the most important one.
Let's have a closer look.
I temporarily updated my application
to print out the value of that header to the logs,
just for our demo today.
For security reasons, I wouldn't do this in production.
So let me open the logs and find one of those log statements.
Here's one.
I will copy the value.
MARTIN OMANDER: The header name contains JWT.
Is it a JSON web token?
XIAOWEN XIN: Yes, that's right.
If I decode it at jwt.io, we see that it
contains the email and user ID.
MARTIN OMANDER: So your Cloud Run service
has code that extracts the user ID and email
from each incoming request?
XIAOWEN XIN: Yes.
And here it is.
This is the source code that ensures
that Google signed the JWT.
MARTIN OMANDER: So you know it was
Google who sent the request and not somebody else.
XIAOWEN XIN: Yes, exactly.
And to be doubly safe, the validation
also checks that the request is for this Cloud Run service.
This audience parameter identifies a load balancer back
end, which in this case is my Cloud Run service.
MARTIN OMANDER: And where did you find that audience string?
XIAOWEN XIN: Here.
It's here in IAP, under the dots menu.
MARTIN OMANDER: Mm.
Very good.
It looks like a useful code snippet.
I will include a link to it from the video description.
OK.
I also want centralized access control for my applications.
So I have a project here with the Cloud Run service that
is a corporate directory, and it should only
be visible to people with accounts in my domain.
But right now, it's public.
So I've already set up a load balancer with a custom domain.
XIAOWEN XIN: Nice.
Show me what you've done.
MARTIN OMANDER: So it was pretty easy to create a load balancer
and add the custom domain to my Cloud Run service.
I just click my Cloud Run service.
I click the Integrations tab.
I pick the Custom Domain Integration
and filled out and submitted the form.
So it took a while.
Now that it's all done, it looks like this.
And then I updated the settings at my DNS hosting service
with this IP address here.
And my domain name now leads to my Cloud Run service like so.
And I can also access the service through the run.app URL
that Cloud Run created, like this.
XIAOWEN XIN: Looks good.
So this is your current setup.
And as you showed, there are two paths to your Cloud Run
service, and neither of them is authenticated.
MARTIN OMANDER: And I want to force
users to go via IAP, where I can set who has access
and who doesn't, right?
XIAOWEN XIN: Right.
That is where you want to be.
An anonymous internet user will no longer
be able to reach your Cloud Run service directly.
Users will have to go through your custom
domain and your load balancer.
And they will have to authenticate with IAP
before accessing your service.
MARTIN OMANDER: OK.
It looks like I need to change a few different things.
XIAOWEN XIN: Yes.
Here is your to-do list.
First, configure IAP.
Then, number two, grant your users access to IAP.
Then, number three, allow only IAP to invoke your Cloud Run
service.
After that, number four, deny anonymous users
from invoking your service by requiring authentication.
And finally, number five, deny external access to the run.app
URL for your service so the only entry points
will be through the external load balancer,
using your custom domain name.
OK, let's do the first item, which is to configure IAP.
MARTIN OMANDER: All right.
I'll go to Security and then Identity-Aware Proxy.
I'll enable Identity-Aware Proxy.
We'll give it time to turn on.
Now I'll go to IAP.
Looks like I need to configure a consent screen?
XIAOWEN XIN: Right.
This is the OAuth consent screen that
will be displayed to your users on the login screen.
Click the button to configure it.
You will only authenticate internal users,
so you will not need to submit your application for review.
Now, fill in the required fields,
and you can always come back later and fill in the rest.
MARTIN OMANDER: OK, I'm filling out the required fields.
I click Save and Continue.
I don't believe I need additional OAuth scopes.
I don't want to access users' spreadsheets, calendars,
or anything like that.
I just want to give internal users access
to this Cloud Run service.
XIAOWEN XIN: Sounds good.
Now, go back to IAP.
You will see your Cloud Run service name there.
Turn on IAP for it.
MARTIN OMANDER: OK.
I will check the checkbox and click Turn On.
Looks like it's done.
XIAOWEN XIN: Great.
Let's just give it a few moments for all the changes
to propagate on the back end.
Then, open an incognito window and go to your domain.
MARTIN OMANDER: All right.
Doing so now.
Aha, there's the login page.
XIAOWEN XIN: Very good.
Now let's go to step number two, which
is granting some users access to your corporate directory app.
Go back to IAP and check the checkbox for your service.
MARTIN OMANDER: Right.
I click Add Principal like you did before.
Then I enter my admin account.
I also enter user in my domain, Alice.
Then I give myself and Alice the role IAP secured Web App user.
Done.
XIAOWEN XIN: Great.
And you can also grant access to groups.
That's easier if you have many users.
I use Google as my identity provider,
so I create the groups at admin.google.com.
Also, look here.
I created an "everyone" group.
It includes all the users in the organization.
The Docs describe how to set that up.
Now you're done with to-do item number two.
In item number three, you will get access to IAP
so that it can invoke your Cloud Run service.
The documentation page for using IAP with Cloud Run
shows the service account that you should grant access to.
MARTIN OMANDER: Right.
I see the account name here.
I'll copy it.
It looks like I need the project number.
I'll go to the Project Overview page to get that.
And then I put that in the account name.
I copy the account name so I can give it access
to invoke my Cloud Run service.
Then I go to Cloud Run and pick my service.
Then, I click Add Principal.
I paste in the IAP account.
I have my copy buffer.
And then I give it Cloud Run Invoker role.
Done.
XIAOWEN XIN: Now it's time for item number four--
deny anonymous users from invoking your service
by requiring authentication.
That's under the Security tab.
MARTIN OMANDER: OK.
I click the Security tab for my Cloud Run service,
and I change it to Require Authentication.
And there, it's done.
So will this change display, that login screen for my users?
XIAOWEN XIN: Not quite.
IAP will display the login screen.
This option, Require Authentication,
means that only authenticated requests from other services
can trigger the Cloud Run service.
In our case, users will authenticate IAP,
and IAP will authenticate the Cloud Run.
And now, you've done four out of five to-do items, Martin.
MARTIN OMANDER: I wish all my to-do lists were that easy.
XIAOWEN XIN: Me too.
And your last to-do is number five,
deny external access to the run.app URL.
You do that from the Networking tab on your Cloud Run service.
MARTIN OMANDER: OK.
I click my Cloud Run service here.
I click the Networking tab.
And here, I set it to internal access,
and I allow traffic from the load balancer.
Done.
XIAOWEN XIN: Great.
Now open an incognito browser window
and see if everything works.
MARTIN OMANDER: All right.
Here we go.
First, I'll make sure that the run.app URL for my Cloud Run
service has been blocked.
I'll enter it here.
Very good.
That URL does not lead to the Cloud Run service anymore.
Then I'll go to my custom URL, which should work.
There's a Login page.
Good.
I'll enter my credentials for admin, not my domain.
And I'm in.
It worked.
XIAOWEN XIN: Congrats.
You have completed all of your to-do items,
and your IAP setup is complete.
Only the users you grant access to in IAP
will be able to access your company internal web app.
MARTIN OMANDER: All right, Xiaowen.
This looks great.
But what if an organization keeps its user list
in Active Directory?
Can they still use IAP?
XIAOWEN XIN: Yes.
If your users are in Active Directory,
and they're using Google Cloud, you
may want to use Google Cloud Directory Sync to synchronize
your Google users and groups to match
the information in your Active Directory or LDAP server.
That way, you can use IAP and other identity-aware products
in Google Cloud.
MARTIN OMANDER: Nice.
So let's recap, Xiaowen.
What are the takeaways?
MARTIN OMANDER: Sure.
Our top takeaway is that you can use IAP as a central place
to secure all of your Google Cloud applications
hosted on Cloud Run, App Engine, Compute Engine, and Kubernetes
Engine.
MARTIN OMANDER: And what's next for anyone
who wants to try out IAP in their project?
XIAOWEN XIN: Set it up today.
This basic version of IAP is free.
All you have to do is pay for the load balancer.
If you want to upgrade your security even more,
check out BeyondCorp Enterprise.
BeyondCorp Enterprise is Google's zero-trust solution
that provides full, context-aware access, including
user and device context, and has integrated threat and data
protection to protect your users from unsafe activity.
MARTIN OMANDER: Thank you for joining me today, Xiaowen.
XIAOWEN XIN: Thanks for having me, Martin.
MARTIN OMANDER: And thank you, everyone, for watching.
If you have questions for Xiaowen or me,
please add them in the comments below.
Also, let me know if there are any other serverless
topics you'd like to see in future episodes.
I read every single comment.
Until next time.
[MUSIC PLAYING]