MARTIN: Today we will talk
about a large enterprise called Big Corp, Limited. They want to centralize access
control to their web apps, both internal and external. Charlie, how could they do that
with Google Cloud platform? CHARLIE: Well,
right now there are a lot of different groups
of admins and developers controlling websites
at Big Corp, Limited, and they use a lot of different
frameworks and languages. We're going to see how Google
Cloud platform can help them control access to
all those sites without having to change them. It will all be centralized
control instead. [MUSIC PLAYING] MARTIN: Let me introduce
you to Marissa. She's a systems administrator
at Big Corp, Limited, and her team has
to manage access to all these
different web systems. She has to solve all
of these problems that Charlie told us
about a minute ago. Marissa and her team has
outlined four different use cases. First, Big Corp's public
website, of course, needs to be
accessible by anybody out there on the
internet, anonymous users. Second, their support
area of their website needs to be accessible
by anybody as well, but we have to know who it is. Users have to log
in so they only see their own support tickets. Third, employees at the
company, and contractors, and occasional
other people who are on the inside of
the company, will need to be able to see the
intranet and their internal web applications. And fourth, some employees
in certain teams, like support team,
they'll really get to see customer PII,
Personally Identifiable Data. But only if they are
on secured machines. So Charlie, can
Google Cloud Platform help Marissa with these
four access levels? CHARLIE: Yes it can. I've been in Marissa's
situation in a previous job and also created
new website services that require user authentication
and access control. So I know this can
be a very challenging technological management
and configuration issue. The Google Cloud platform has a
tool that can help enormously. It's called
Identity-Aware Proxy. It's a great fit for
Marissa and her developers, and it's a service
that controls access to those websites for them. The nice thing is it can do
this without changing those web servers in any way. MARTIN: That sounds great. Just the ticket for Marissa. How would this actually
work in practice? CHARLIE: Well, let's take
a look at an example. Here, we've got an
internet-facing website that needs to control access. And it's got three potential
users on this picture. The general public, somebody
that doesn't authenticate themselves at all, a
real authorized user, and then somebody
that can authenticate, they've got credentials,
but they're not one of the people the
site wants to talk to. So right now, all of their
requests hit this server. And it's the web
server's responsibility to decide which ones to respond
to and which ones to ignore. Identity-Aware
Proxy is a service that sits right here, between
the server and the internet. All the requests coming from
the internet to the web server now go through
Identity-Aware Proxy. Identity-Aware Proxy
prompts users to log in. And after they log in,
it uses their identity and Marissa's configuration
to decide who to let through. And only requests
coming specifically from the authorized
users ever actually hit the web server at all. Now, in order to do this,
the users do have to log in. And they use Google's
Identity Service, which handles Gmail
and G Suite, basically all of those different
possible addresses. MARTIN: OK. That sounds pretty good. But how about if Big Corp
isn't using a Google identity? I know, for example, my
last employer before Google, they use Active
Directory instead. CHARLIE: That's
certainly pretty common. And Google solves
that with IAP as well. Marissa's corp can synchronize
their Active Directory with the Google
Identity Service, and then all the users
in their Active Directory can be verified by Google
and used to configure IAP. Once IAP knows who
each user is, it can simply block the
users that should not come through the website. They can't see it at all. And the web server
doesn't need to worry about is that somebody we should
respond to or not, because it never even gets a request
in the first place. MARTIN: Nice. Yeah, anybody who's had a web
server on the public internet knows that you get a
lot of weird traffic that you probably
don't want to see. CHARLIE: Absolutely MARTIN: So, Charlie,
this looks good, and we can keep the
unauthorized users out. But what if that web server
over there on the left actually needs to
know who is accessing? CHARLIE: Well, this picture
shows IAP controlling who can come through and have
the request come to the web server. But IAP has another trick up
its sleeve that I really love. When it sends a request
through it, it adds a header. In fact, it has three headers. And those headers
include the identity of the user that
authenticated IAP. So now if the web server does
want to know who that user is, it could just check a header. It's hard to have
something easier than that in any kind of
a web server framework. So it could find
the email address. It can find a persistent ID. There's a lot of
information that's available in those headers. MARTIN: OK, cool. You mentioned different
frameworks and platforms. And, of course,
Marissa's company, they have lots of different
frameworks and platforms. Which of these
does IAP work with? CHARLIE: As you'd
expect, IAP can protect services running on a
lot of Google Cloud platform infrastructure, such as
App Engine, Compute Engine, and pretty much anything that
could be behind a Cloud Load Balancer. But it also can protect stuff
on the company's own premises using something
called IAP connector. That's going to require some
extra network configuration to route the requests from
IAP back on to the company's own premises. But once it's set up, then it's
configured for access, just like any of the other
things behind IAP. All this is straightforward MARTIN: OK. It looks pretty straightforward
here in slide four. How would Marissa actually
go in and set this up, in real, practical terms? CHARLIE: All right,
well, I've set up a demo project on
Google Cloud platform with five sample websites. Let's take a look at
that on the console. Here we see the console
control page for App Engine, and there are five websites
set up here for App Engine. One of them is the public one
at just plain bigcorpltd.com. There's one for customers
to send in support requests, one for the customer support
staff to respond to them, and a couple of
internal websites for different purposes. One that's open
to all employees, one that's more restricted. IAP can configure all
of these situations. Now right now, all
five of these websites are wide open because
we haven't enabled IAP, and we're going to fix that. MARTIN: Right. Yeah, that doesn't
seem very safe. Is there some way
Marissa can not expose the company internal
stuff, not even for a minute, not even for a second? CHARLIE: Well, it
turns out that in order to turn on IAP to
protect something, something needs to
be there already. So what I would
do is I would just deploy a simple hello, world
website so I could enable IAP. And then when I put
more websites out in the same project, they
would be protected by default. And I could then configure
them to whatever way I wanted them to be so it could
all be a little bit different. OK, so let's get started. Here we have our App Engine
project with a lot of websites to protect, so we've got to turn
IAP, or Identity-Aware Proxy, on for it using
the card console. The Cloud Console menu
has the different commands organized in groups, and IAP
is under the security group. Identity-Aware Proxy. So here we see all
the different HTTPS, that is web servers, that
are protectable by IAP. All those App Engine ones are. To protect them, all I got
to do is flip this toggle. That's it-- MARTIN: That was easy. CHARLIE: --they're protected. Now, if this were-- MARTIN: Yeah. CHARLIE: --the first time I ever
turned on IAP in this project, I would be prompted to
fill in a form for what we call the consent screen. And that basically
is describing who's asking the user to log in. So when Google puts
the launch screen up, it can say this is for
bigcorpltd.com, that's who you're logging in to. MARTIN: All right. So now this is set up here. And what happens if you
hit the public website now? CHARLIE: Well, it
takes a few minutes for changes to IAP to
propagate, because it's a worldwide service. But once that's done, we'll
open a fresh incognito browser, so there's no logged-in
user already cached, and try to connect to
the corporate website. And I'm immediately
asked to sign in. Well, I can sign in with
my bigcorpltd.com account. MARTIN: Oh, you work
at Big Corp, Charlie. I didn't know. CHARLIE: Just temporarily. And-- MARTIN: Temporarily. CHARLIE: --now I see
that IAP is blocking me. MARTIN: Uh oh. But that is a little
weird, because I did not see you turn off access
for anybody, Charlie. CHARLIE: I did not tell
IAP to deny anybody access. But I turned on IAP,
and I didn't tell it to let anybody in, either. And that's the way it works IAP
doesn't say who to keep out, it says who to let in. So we're going to need to go
in to tell IAP to let users in to this public site. Let's go ahead and
configure the public site. Remember the use cases
we were looking at. The first one is
everybody in the world should be able to get to it. This is just a regular
public commercial website. MARTIN: Yeah so this
seems a little odd, I think, for IAP,
because it worked, it was public for
everybody a minute ago. We now turned it off with IAP. Do we even need IAP
for this use case? CHARLIE: Well, yes. This is kind of an odd use
case because we had a site that was already open to the public. We turned on IAP,
nobody's allowed in. And now we're going to configure
IAP to let everybody in again. The reason for this is that IAP
is global across this project. So the public website is in
the same Google Cloud project as the other ones, so
when I turn on IAP, it affects it as well. Luckily, I can tell IAP,
pretend you're not there. Let the public through. Let's go ahead and
do that right now. Take a look at how
we configure it. Here we see the public website,
which is the default one. When we select it,
we have an info panel that shows who's got
various access to the site. And what we want to do is
add a member to the site, this is how we let
somebody through, and we just need to put,
say, their email addresses. So we can put everybody's email
address in the world here. But that's not really
what we want to do. MARTIN: That's a lot of typing. CHARLIE: So there's
actually a special case that I need to type. All users is a special IAP user. To give anybody access, I need
to give them an IAP secure web app user. Save that. Yes, I want to
allow public access. And remember, it'll
take a couple minutes. But now, after
that's propagated, when somebody goes
to that website, they won't even see IAP at all. They won't be
prompted to log in, they'll just be sent
directly to the site. OK. We've waited a
couple of minutes, so the changes
should be propagated. Let's open a fresh
incognito web browser. So nobody's been logged into
anything through it yet. MARTIN: Mm-hmm. CHARLIE: And it'll take
a second to go through. Didn't prompt me to log in. Anybody in the world
was allowed to connect. Just as if we didn't
have IAP at all. There are probably easier-- MARTIN: All right. CHARLIE: --ways to write
that than turning on IAP and then configuring it. But we're going to see
more valuable uses of IAP in a few minutes, MARTIN: I see that Big Corp
like minimalist web design. CHARLIE: It was very
minimalist web design, yes. MARTIN: Yes. All right, so, cool. That was public access. Perhaps the simplest use case,
and maybe the least interesting one. Let's move on to the second one. I think this is a
lot more interesting. So users-- anybody can log in,
but they must be authenticated. How does IAP do this? CHARLIE: From the IP
management point of view, this is almost identical. We want IAP to let
everybody through. However, we're saying,
before you let them through, authenticate them, and pass
through headers telling us who you authenticated them as. So if we go back to the
console, instead of default, we go to the support site
the general public will use. And again, we add a member. And the only difference here
is, instead of adding all users, you add the special use case,
all authenticated users. Again, we grant them the role
of an IAP-secured web app user. Save it. And warns that we're making
it available to the public, but only authenticated
members of the public. And after it propagates
and we connect to it, we'll see that the
site knows who we are. OK. So let's go in a fresh
incognito browser, and go to that customer support
site, support.bigcorpltd.com. And we told this to
let everybody through, but we said authenticate them
before you let them through. I'm going to use the
same dummy email account, but it really doesn't
matter which one I use. It could be anybody that
Google can authenticate. Oops. And it can only authenticate
me if I type the password in, right? Now I'll pass you
through to the account. Take a second for the website
to spin up to respond. And notice that it says
welcome, engelke@bigcorpltd.com. The website knows
my email address. MARTIN: That's your email. CHARLIE: I didn't
have to do anything. MARTIN: Yeah. CHARLIE: I didn't have
to log in to the website. IAP told the website who it was. MARTIN: So how does IAP do that? How does this work? CHARLIE: Well, the
way it knows that-- let's go look at the
picture we had earlier. Of all your tests coming in and
being intercepted and adding headers, these are the
headers that it adds. Three headers, one called
X-Goog-Authenticated-User-Email, then
X-Goog-Authenticated-User-Id, and X-Goog-Iap-Jwt-Assertion. Here are some examples
of the values. The authenticated user email
one is my email address that IAP verifies,
it stands behind it saying I really checked. That's who this really is. The user ID is kind of an opaque
identifier that Google uses, so that every time
I go to the website, I'll have the same
identifier, but the website won't necessarily
know my email address. That way it could store
that if it wanted to. Only give me my response
back, but without storing something potentially sensitive,
like an email address. The final one's a little
bit more complicated. It's the JWT header. MARTIN: What is the JWT header? CHARLIE: Well, that's showing-- MARTIN: I see base64. CHARLIE: --it all because
this goes on and on and on. It's a very long basic
ensure encoded string that represents a
digitally-signed record that has a user ID and email in it,
which from the other headers anyway. But the fact is, depending on
how the company servers are configured, particularly if
you're on your own data center, you may have the path from the
internet to your website server that has to go through IAP. And you may have other
paths from other machines inside your data center network
that can send requests to IAP. And if you're concerned
that those other machines in your data center
could be compromised, they could send fake
requests to that web server, and they could add a header that
says this is by email address, even though it really isn't. The digitally-signed
JWT can't be spoofed, because it's digitally
signed by Google with Google's private key. So the website can simply verify
it and decode it, and make sure that it didn't get spoofed. So in the description
below this video, we've got a link that points
to the documentation on things like JWT in general. And there's a
codelab specifically on how to decode that for
the Flask Python program that's being protected by IPSec. MARTIN: OK. So what I'm hearing is,
for many developers, it'll be enough to just look
at the email or user ID header. But if you want additional
security within your project or data center, then you may
want to verify the JWT header. CHARLIE: Yes, the more
control of networking options that are in use, the more paths
there might be to the server on the back end that don't
go through the front door. And then you'd be
concerned about it. But in a case like
this with App Engine, there aren't any such
paths, for our example. So we can do it the simple way. MARTIN: Oh, OK. Oh, excellent. All right, cool. So we talked about the
first two use cases. They're about public
access to the website. Now what about the
third use case? So remember, this was the
one where only Big Corp employees should be able to
hit their internal web apps. CHARLIE: Yeah, that
everybody needs to do. And when people first started
doing these internet sites, they would just take an
unprotected web server, but put it on the
internal company network. So anybody else that's on
the internal company network can get to it, people who
aren't can't get to it. Great. But it-- MARTIN: Yeah. CHARLIE: --opened a
lot of other problems. MARTIN: What's wrong with that? CHARLIE: That website
trusted everybody on the internal company network,
every device that was there, which might not be a good idea. And an even bigger problem-- MARTIN: Oh. CHARLIE: --that
occurred over time is employees are less and less
likely to be in the main office and connected to that
internal network. They'd be on the road. So the solution
to that was let's set up a virtual
private network so they can connect to the internal
network through the internet as if they were on
the internal network. That gave them the access,
but it opened up again a whole new set of problems. It was hard to
configure and support, and it meant that this
outside machine now had access to everything, not
just the employee's website. IAP gives us another solution. So remember the picture of
how IAP protected access. All other requests
had to go through it and it only let
a request through if it was one of the
users you wanted. So Marissa can simply
configure IAP and say, only let through people who
really are employees, who can prove they're employees. So the web requests
that come through IAP will just be this
kind of request that might have come in your
internal network for employees. You're protected from all
the rest of the internet. And the end user
doesn't need to have a VPN client or anything else. They can just connect
with any web browser. So long as they can
authenticate themselves. Now, configuring this
is very similar to what we've seen before. So let's go back
to that console. And let's go to the
employee website. And we need to add a member that
represents all the employees. Well, Marissa's company
synchronizes their Active Directory for all email
addresses at bigcorpltd.com to Google. So all they need to do
is say bigcorpltd.com, and every one of those email
addresses is now allowed and no others are. Typically, they may
have other people that want to treat as
employees for the intranet, but who they don't want to
give email addresses to. Maybe they're temps or
they're contractors. So they can set up a group
with all those email addresses, and they can add
the group as well. They don't have to enter
each individual address. And then HR can manage that
group as new temps come in and new contractors go out. While enabling it is the same
thing we've seen twice before. Give them the IAP secured
web app user role. And now, in a few minutes-- we're not going to
wait and show it, 'cause it's the same kind
of thing we've seen before. But anybody that tries
to go this employee site will be intercepted by IAP. And only if they're
an employee or one of these people in that group
of temps and contractors will they get through. Let's look at the
customer support site that the customer
support staff uses. They're going to
log in, and they're going to see the
requests from users, and they're going to see those
users' email addresses, which we don't want the
public in any case, ever, to be able to get to. So we want to make sure that not
only are the people connecting a member of the
customer support staff, but if they're using, say,
a personal laptop, that they don't use something that
doesn't have a screen lock, and they leave it logged in,
they walk away for a minute, and somebody steals it, they're
still logged into the site and see this data. You want to make sure that
we can't have that happen. So Marissa's company said,
we want the support staff to be able to connect
when they're remote. That's very, very common. And we want to restrict
it to only those staff. We want to go further. We only want them to
connect if they're using a machine that has a
screen lock enabled and has the hard drive encrypted. So if the device
is lost it doesn't give the person who takes
it access to that site. MARTIN: Oh. Can IAP do that? Does it know when
machines have been stolen? CHARLIE: Yes it can. This is one last little
trick IAP has for the moment. Configuring it to do that looks
a lot like the other use cases with a little bit of
a twist at the end. Let's go ahead and take
a look and do that. So here we see the IAP page and
the customer support website. We're going to add members of
the customer support group. And we're going to give them
IAP-secured Web App User. But before we say go
ahead and save this, we're going to
add a restriction. Only let them do it
if they're connecting from a machine that meets
the needs of a safer client. Now, when somebody from
the customer support group logs in, even if they
properly authenticate, they won't be let
through if they're on a machine that doesn't
have a screen lock or doesn't have an
encrypted hard drive. Now, that's all configured
in Access Context Manager. Here's that safer client policy. You can see it says devices have
to have a device screen lock and they have to have
encryption turned on. Enable. Just for a quick look, there
are a lot of other things that can be put in as well
if they were appropriate. For example, they
can restrict access to specific IP network ranges. They can also restrict
access to certain regions. Perhaps they want
to only allow people to access it from
the US and Canada, or only from European
Union countries. They can select those
countries, and only those people will come through. The device policy we are using
can be made more restrictive. The machine not only might
have to have a screen lock and encrypted
storage, but maybe it also has to be a machine that's
been specifically approved, or even a machine
that the company owns. And it can also restrict which
operating systems and operating system versions are allowed. I'm not going to add
any of those conditions, because this is
strong enough for what Marissa's company needs. Now, in order to
do that, IAP needs to know some stuff about
the end user's machine, like the screen lock and
the encryption level, that a browser normally
won't tell a web server, normally wouldn't tell IAP that. So the users are going
to have to have a work profile on their phone or Chrome
extension in their browser that tells them that. That's available for anybody,
if they are using G Suite and are connected to
a corporate profile, it'll do that automatically. And that basically
says, when you're connected to IAP
for our company, let it know this information
about your machine, so it can decide what
level of access to provide. And that's it. IAP can handle all
these four use cases, which are pretty universal. There's a lot of different ways
you configure and fine tune it. But the nice thing about
it is, Marissa can do that, and the app servers
that are out there don't have to change at all. MARTIN: Oh, nice. I think Big Corp
will eventually be able to delete a lot of
their authentication code they've sprinkled all
over the web apps. CHARLIE: I think so, too. MARTIN: Thank you for
showing us this, Charlie, and thank you all for tuning in. If you have questions about
how IAP works or any security questions on GCP and serverless,
please post them in comments below. Or if you have questions
about, or requests for, other videos we should create
around serverless, please let us know. Thank you for this time. See you next time. CHARLIE: Bye. [MUSIC PLAYING]
