[MUSIC PLAYING]
NAVEEN CHAND: So my
name is Naveen Chand.
I'm a product manager.
I work on Google Cloud
and identity on GCP.
Today I'll be
presenting with some
of my esteemed colleagues,
Blake and Breno,
who you'll get to
meet in a few minutes.
So why are we here?
GCP offers a myriad of
different identity capabilities.
But what are the best
identities features
to use in specific scenarios?
Today, in this talk, we'll
walk through a overview of many
of the different capabilities.
We won't be going
super deep into them.
But we'll give you a
good end to end picture
of what that would look
like and how you can
stitch your solution together.
We'll also link you to many
of the other talks that
will be taking
place that will deep
dive into many of
the technologies
that we cover today.
In order to walk through
the scenarios today,
we're going to be introducing
a company named Zotkix,
which is a fictitious
company that is
a multinational organization.
They have a
distributed sales team,
where they have
salespeople that are coming
from many different locations.
They have a customer
facing portal.
And one of their top
objectives for 2019
is really this motion of
digital transformation.
So today, some of
the goals for Zotkix
is really to get their
users onboarded onto GCP,
make sure they're
able to protect
their sensitive
accounts, securely
and scalably manage
access to GCP,
be able to seamlessly
enable their distributed
salesforce to get access to
GCP in a quick and efficient
manner, making sure that they
can administer authentication
and authorization consistently
across their environments.
And really, they have a
customer facing portal as well
that they wish to reduce the
complexity on the identity
aspect.
So digging in a little bit
into their architecture,
they have a few different
types of identity
that Zotkix handles.
There's employees,
partners, and services,
which are all represented
in their Active Directory
instance in this case.
They also have a homegrown CIAM,
or Customer Identity and Access
Management solution, which
powers their portal page.
And that's where their end user
identities are actually stored.
So the first thing we're
going to walk through
is really how does Zotkix go
and grant access into GCP?
So we'll be highlighting a
few of the identity types.
So administrators granting
access, developers, and also
groups that encompass both of
these different identity types.
So after Zotkix is
registered with GCP
and created an
organization, they
need to give their admins
and developers access
to the platform.
In order to grant access
to their developers,
they use Google Cloud Identity,
which is a Google service that
allows customers to create,
manage users and groups
and how they'll have
access to cloud resources.
In addition to
granting access to GCP,
Google Cloud Identity is a
complete [INAUDIBLE] offering
that is also available
as a standalone product,
supports robust lifecycle
management, device policies,
and provisioning across a
multitude of applications.
So as Zotkix masters all
their identities on-prem,
the first step is really
to get those identities
inside of cloud identity.
And they can leverage
one of GCP tools called
Google Cloud Directory
Sync, or GCDS for short.
This tool allows
you to go and select
which users in your AD instance
by doing either an LDAT filter,
selecting specific
OUs, but saying these
are the set of folks that I
believe need to get access
to my GCP resources.
And so they can synchronize
those identities over.
The next step is actually
granting single sign
on for these people.
So in addition to
having representation,
they want them to be able to
use the username and password
that they use with their AD
instances in order to get in.
So in order to
achieve this, Zotkix
could go and configure
a federation broker
and use protocols
like SAML in order
to go get single sign
on working with GCP.
If Zotkix happened to use one of
these other identity platforms,
they could have used some
of the capabilities that
are built into them that allow
these platforms to directly
provision into Google
Cloud Identity.
So we talked about employees.
We talked about customers.
Talked a little bit more about
service accounts for a second.
As service accounts
are really an identity
for your application that enable
programmatic off fabric access
in many scenarios, as well.
We're going to walk through one
specific example in which you
have an application
that's running on premise
that needs to get access into
GCP, in this case, the GCS
bucket.
So in order to do this, because
you have an application,
you don't want to
have a user name
and password stored
somewhere locally
on your on-prem environment.
So that's why you would
create a service account.
And with that
service account, you
could take a service account
key, or create a key on it,
use that from the
oncoming environment
in order to be able
to authenticate up
to Google Cloud.
Now, some of the best practices
with service accounts,
because the service
accounts, or robot accounts,
are usually fairly powerful.
As always, the principle
of least privilege
is extremely important.
Also, controlling your service
accounts through policy.
We'll be talking about a few of
the different policy types that
are possible and allow
you to go and have
much more granular control over
where service accounts are used
and how they're used.
Using features like
descriptions that
allow you to go
and specify this is
the intent, why this service
account was actually created.
And then the last and one
of the most important parts
is really to protect
those downloaded keys.
So developer keys
should not have access
to prod resources, for example.
Making sure that those
keys are actually rotated
and having a recurring cadence
through which you actually
do rotation.
And then auditing
the service account
keys that have also been
created in your environment.
So we've talked about how
Zotkix was able to go and grant
their users access into GCP.
They're now able
to single sign on.
The next step is
really to take some
of those sensitive
accounts and make sure
that we have an extra layer
of protection on top of them.
And for this, one of the best
practices that we recommend,
especially for the highly
privileged accounts,
is using security keys.
So based on final
standards, security keys
are phishing-resistant
second factors
that use cryptographic challenge
and responses to provide
integrity of the
authentication session.
So keep your eyes peeled.
There'll be an
announcement coming on 4/10
on something new in this area.
So just looking at the next
level inside of security keys,
just to learn a little bit
more about how they work.
The core idea is
in this case, Alice
is navigating to a website.
And when she tries to
sign in, the server
gives a challenge to
the login web page.
The web page asks the browser
for a security key signature.
And then you'll notice
that it passes that
to the security key that
actually goes and encrypts
the entire package, both the URL
that Alice is actually looking
at right now, along
with the challenge that
was sent from the server.
That is sent back up all the
way to the server, which is now
able to see that
Alice's key signed this,
this was the actual
current challenge that
was actually specified,
and most critically,
Alice was actually
pointing to Google.com, not
some other website.
And this is where that
protection around phishing
attacks actually comes in.
If somebody was to send Alice
an email with a link that
said goggle.com for example,
she would actually be able to go
and the server would
actually reject the call.
Realizing that she's
not on the website
that she was actually
intended to be on.
So with that, I'm going to
hand it over to my colleague,
Blake, who's going to walk us
through in access management.
BLAKE T: Hi everyone.
My name is Blake.
I'm a product manager
on Google Cloud IAM.
And I'd like to think
Naveen for kicking us off
with an overview of identity.
Before we get into
best practices,
however, I do want to
have a quick refresher
course in some of the core
concepts that are related here.
And let's start with
the resource hierarchy.
The entire idea behind
the resource hierarchy
is that you can easily map
your organizational structure
to GCP for easy
discoverability of resources,
for delegation, and for
access policy management.
And there are three
key types of objects
that exist in your hierarchy.
The first at the very
top is your organization.
This is automatically
provisioned
when you sign up
for Google Cloud.
And everything, every GCP
service, every project,
every folder, will exist
underneath this object.
And so next, let's
talk about folders.
Folders are really used for
splitting up your GCP resources
in a manner that matches
your internal structure
and is conducive to
administration and policy
management.
There are definitely
some best practices
here that we'll get
into momentarily.
But at least within
GCP right now,
you are allowed up to
four levels of folders
for organizing your resources.
And finally, you have projects.
By number, at least, besides
the services themselves,
these are probably the
most numerous resource
type you're going to
have in your hierarchy.
And ultimately, your
workloads and GCP services
are going to reside
inside of a project.
Now some GCP services do allow
for more granular management
of access policy below the
project level, but most don't.
And so this is going to
be a frequent attachment
point for your access
policies in GCP.
So let's talk about
Cloud IAM itself.
Cloud IAM is really all about
who can do what on which
resources.
And we've already
talked about the who.
Naveen took us through users,
groups, and service accounts.
So let's really
start with the what.
The what is what a
principal can do.
And that is done through
the granting of permissions.
Now in GCP, you cannot actually
directly grant permissions
to a principal.
This is done through
the use of a role--
roles being groups
of permissions.
And lastly, the on
what resource part.
So in GCP, you apply policies
to the resources themselves.
And so the typical
attachment points
in your resource
hierarchy are going
to be that organization, your
folders, or your projects.
And it's important
to note, there's
actually a pretty big benefit to
attaching policies in this way.
Which is that the role, or
in effect, the permissions
that the principal
gets, can be different
for different resources,
depending on where
you attach those policies.
Now the notion of inheritance
is also very important here.
Because based on where you apply
a policy in this hierarchy,
the access that
you've granted is
going to inherit down to
everything below that level.
Let's take a quick
look at an example.
So here, let's say you gave
a bucket Admin role to a user
at the organization level.
That user is now able
to access any bucket
inside of that organization.
Similarly though, let's say that
you granted that role to a user
on that first folder.
In this case, they're able to
access all the storage buckets
only underneath those
first two projects
because those projects are
underneath that folder.
And finally, applying that
policy to an individual project
would only grant the user
to the three buckets,
for example, in
this first project.
So to round out our
refresher, let's take
a view of what a policy
actually looks like.
Now keep in mind
that since policies
are attached to resources,
the applicable resource
is really implied
through that attachment.
So what's in the policy
is primarily two things.
One, the role, which again,
a collection of permissions.
And two, the
members, who you are
granting those permissions to.
Now there are two
key focuses here
as we get into best
practices to make life easier
for a company like Zotkix--
a large company like Zotkix.
The first, is that we want to
make administration manageable,
to make policy
administration manageable.
Zotkix also wants to make
sure they're doing everything
that they can to achieve that
principle of least privilege.
So for the first, one of the
best things that Zotkix can do
is make sure that they start
off using their resource
hierarchy correctly.
Since we know that
Zotkix is a large company
with multiple business units
that do operate for the most
part independently,
we can make that
our first layer of folders.
You've got your three
business units up there.
Underneath that,
let's say potentially,
one folder per team.
Below that a folder for an app.
Below that a folder
for an environment.
The benefit to arranging
things in this manner
is that Zotkix can significantly
reduce the number of policies
they need to manage, while
also maintaining the desired
isolation they want
between their business
units, their teams,
their applications,
and their environments.
So to look at a
few use cases here,
so cloud administrators, for
each of their business units,
can be granted the
necessary access
at each of these
top levels and have
that inherit down to everything
in their business unit.
SRE on-call groups could
be configured at the team
or app level folders for
what their supporting.
Engineering teams can be given
their foundational access
at the team level, with only the
more granular policies applied
down below.
So by making use of the
resource hierarchies,
Zotkix was able to
avoid having to specify
all of these policies in
a very duplicative way
separately on all
of their projects.
Now moving on to
achieving least privilege.
Zotkix has a few options
available to them.
While they started out
using the primitive roles
that we offer in GCP,
owner, editor, and viewer,
they quickly found these to
be far too permissive when
it actually comes to achieving
that principle of least
privilege.
And as a result, they
started using curated roles
for their access grants.
These have narrower access.
They're generally focused
by service, and even
further by persona or job role.
So there are several
hundreds of these roles
in GCP that Google
creates that they curate.
You can see some
examples of those here.
But for some of
their grants, Zotkix
found that even the curated
roles that we were providing
were close but not exactly
what they were looking for when
it comes to granting access.
And so as a result, they decided
to take a look at custom roles.
Here for example,
they copied one
of the BigQuery curated
roles and removed
a couple of permissions
they didn't want to grant.
In other cases,
Zotkix can do the same
but add a few
additional permissions.
They could also combine
two curated roles
to simplify their access grants.
Finally today, let's take
a look at a feature that
will be entering
public beta soon
that will allow Zotkix
to configure their access
controls in even more of
a finer grained manner.
IAM conditions adds a layer of
attribute based access control
on top of the role based access
control concepts that we just
went through.
Essentially, this allows you
to configure role grants that
provide access to
a principal only
if certain other
conditions are also met.
One such example of a condition,
would be granting access
based on time.
There are a couple of
different ways you can do this.
One would be
configuring an access
grant that is only valid before
a specified expiration time.
This can be helpful for
break glass scenarios,
such as giving a developer two
hours of access to production
to fix an issue knowing
that that access grant will
be automatically revoked.
This could also be done
as part of a recurring
schedule-- granting
access to a resource,
let's say Monday through
Friday, 9:00 to 5:00.
Another use could be during
project level grants that
only allow access to some
of the resources of a given
type in that project.
For example, you could grant
a compute Admin role to a user
but with conditions, specify
that that user can only
managed VMs whose
name starts with test-
or whatever other prefix
you wanted to use.
And finally, you
can use conditions
for context aware
access, as well.
By configuring a
grant that is valid,
only so long as aspects
of that user's context,
such as their IP address
or device security policy,
are met.
Great.
So now that Zotkix has optimally
configured their access
policies for their
GCP resources,
they're now ready to move
on to extending that access
so that their distributed sales
teams can access internally
built corporate
apps that they need.
Breno will tell you
more about that.
BRENO DE MEDEIROS:
As Blake mentioned,
I'll now cover how Zotkix
can enable similar success
to their apps and
services for usage
by their distributed
salesforce, for instance.
And also how they can securely
support their employees
and developers to work from
home without need of a VPN.
Let's now recap where Zotkix
stands on their modernization
effort.
Zotkix migrated some corp
apps and their consumer portal
to the cloud.
But they still run
several apps on premises.
They want to enable
their employees
to access both sets of
apps from their workplaces,
from their homes,
and on the road.
And they need that their
sales and their partners staff
be able to access
tools and demos.
Both when visiting a
customer's location,
maybe when they are attending
Cloud Next, or anywhere.
So here we introduce the
BeyondCorp security model.
So in starting in 2011,
Google created a new approach
for Access Management, the
BeyondCorp enterprise security
model.
It's a zero-trust
security model.
That means that requests
are not granted just
based on where they
originate in the network.
Instead, BeyondCorp
insists on verifying
that the requester has
permissions to access
the services that they invoke.
So BeyondCorp shifts
access controls
from the network perimeter, to
individual users and devices,
and allow employees to work
security from any location.
So let's look a little closer
on how BeyondCorp works
and how it can help Zotkix.
So first, let's look at the
BeyondCorp solution components.
It requires that,
for instance, you
have a strong notion
of user identity.
It doesn't insist that
you use phishing-resistant
authentication.
But it can leverage that
information, the information
about the session
strength, to make decisions
based on the sensitivity
of the request.
It also requires context
information, such as location,
device status, et cetera.
It requires a rules engine
that allows the IT security
teams to define access rules.
And finally, it defines
enforcement points
that control access to
the various resource
types, such as web apps,
VMs, APIs, et cetera.
So Google Cloud
provides a solution
to enable the BeyondCorp
security model for your apps
and infrastructure.
This solution is called,
context aware access.
It integrates with multiple
Google Cloud Services
to make it BeyondCorp possible
for your organization.
So one of the
components is called,
VPC Service Controls,
VPCSC, for short.
And it improves your ability
to mitigate the risk of data
ex-filtration from
Google managed services,
like Cloud Store and BigQuery.
With VPC Service Controls, you
can configure context aware
security perimeters
around the resources
on your Google managed services.
And you also can
control the movement
of data across the
perimeter ingress controls.
Cloud IAM we covered, thanks to
Blake's presentation earlier.
And for Cloud IAP, as
the Identity Aware Proxy,
it provides the enforcement
point for the ingress rules.
So it's an ingress proxy that
provides level four to seven
network filtering capabilities.
And now, we are going to
see how Zotkix can achieve
consistent security
and access control
management across their
various environments,
between on-premise
and cloud based apps.
So for that, I'll
introduce ISTIO.
If you haven't heard
about it, ISTIO
is an open source
service mesh that layers
transparently onto existing
distributed applications.
It is also a platform,
including APIs,
that let it integrate
into any logging platform,
telemetry, or policy system.
ISTIO's diverse
feature set lets you
efficiently run a distributed
microservices architecture.
And it provides the uniform way
to secure, connect, and monitor
microservices.
So why would you use ISTIO?
ISTIO makes it easy to create
a network of deployed services
with load balancing, service
to service authentication,
monitoring, and more, with few
or no changes in service code.
It can also be used to deliver
a secure service to service
communication in a cluster,
with a strong identity based
authentication,
and authorization
based on mutual TLS.
And with Google as
a major contributor
to ISTIO development
architecture,
it means that using
ISTIO, you can
take advantage of best
in class strategies
for microservice
mesh management.
So you add ISTIO to services
by deploying a sidecar proxy
throughout your environment.
It intercepts all
network communication
between microservices.
One then configures and manages
ISTIO using this control plane
functionality.
This allows, for
instance, Zotkix
to distribute policy about
network accessibility, about
authentication, authorization,
and audit policies,
as well as telemetry
configuration.
The configuration is consumed
by the Envoy proxies attached
to each workload instance.
And policy is enforced
by the infrastructure.
So in particular, why
use ISTIO's security?
So ISTIO delivers
authentication, authorization,
and audit as part
of the platform,
ensuring consistent
compliance and removing
the burden on app developers.
In addition, authorization
can use both the identities
of the requesting user and
of the connecting peer.
ISTIO delivers
automatic metrics, logs,
and traces for all traffic
within the cluster,
including cluster
ingress and egress.
And it improves visibility
to all operations
and consistent audit support.
So now, let's look how
Zotkix can leverage
ISTIO and Google
managed services
to obtain consistent security
across the hybrid deployment.
First, let's look on how Zotkix
addressed access management
for their on-premises apps.
In the examples, I will show
ISTIO deployed in Kubernetes.
In particular, in
this scenario, Zotkix
has deployed a GKE
on-prem cluster.
But I would like to
emphasize that ISTIO does not
require Kubernetes.
It can be used to manage more
traditional on-premises data
centers.
The Envoy proxies deployed in
ingress, as well as a sidecar
in each pod, and it manages
all connections in and out
of the cluster and in
and out of each pod.
So that provides the
ISTIO enforcement point.
Now let's see how
a corp user, which
is authenticated of
their corp credentials,
can access services
in the cluster.
So here, when the corp
user makes a request
to the Zotkix's HR app, Envoy
terminates the TLS connection
and enforces that their request
includes user credentials.
And it can perform any
other ingress checks.
Next, the request is
going to, of course,
be forwarded to the HR app.
And the sidecar Envoy
evaluates authorization rules.
So for instance, it can require
that the authenticating user
have an administrative role,
if a privileged operation is
invoked.
As their request travels
down the services stack,
the HR app calls the
backend, which also applies
the authorization rules.
And these rules, as
before I mentioned,
they can be both based on
the peer, in this case,
is the frontend for the HR app,
as well as the requesting user.
So now let's look
at a situation where
a corp user is accessing
Zotkix on-premise cluster
from overseas.
So to take advantage of
Google's fast and globe spanning
network, Zotkix can
route their remote access
to their on-premise clusters
from the Identity Aware
Proxy in Google Cloud.
IAP provides additional
authorization features,
if for instance, it
can ensure that access
comes from a managed device.
So this shows how BeyondCorp
solutions can seamlessly
extend to protect
Zotkix on-premise apps.
In fact, many IAP
customers choose
to use IAP as their ingress
proxy for all their apps,
whether their apps
on GCP, on-premises,
or in other clouds.
Let's now look at how Zotkix
can protect its cloud apps.
So we are assuming here
that Zotkix has already
extended its identity and
authentication system to GCP
by syncing their Active
Directory with Cloud identity
as Naveen went over earlier.
So in this case, Zotkix has
deployed a legacy application
in a Clouded-Hosted VM.
IAP can be used to provide
ingress enforcement
of authentication
and authorization
when a Zotkix employee accesses
a legacy database hosted
in GCP.
Legacy applications can also be
protected on-premises and when
located in order Clouds.
You can do this using an ISTIO
ingress proxy or using IAP.
And of course, if
you use the IAP,
you got an advantage of the
benefit of the context aware
enforcement rules.
So now, we show
how you can deploy
ISTIO in GKE, using
IAP for ingress proxy,
in this scenario.
Zotkix can configure
role-based access control
in both IAP and in the
Envoy sidecars on each pods.
And for instance, again,
IAP can deliver the context
aware functionality
here requiring,
for instance, the second
factor authentication, or use
of a trustworthy device.
And the Envoy sidecar
proxy can provide
fine grained
authorization, using
service specific configuration.
We can also use the
same architecture
to protect access by end
users of the Customer Portal.
Authentication,
authorization, and audit
are throughout the services
stack at every level.
And this reduces
trust between systems,
which means that it
mitigates the user risk
and it facilitates
compliance activities.
We also look here
about how ISTIO
can enhance security of service
to service communications.
In particular,
ISTIO allows Zotkix
to deploy TLS certificates
in each of their workloads.
So services can now communicate
to each other using mutual TLS
to strongly identify
their peer identity.
Now, let's explore how we can
leverage the native workload
identity of Kubernetes.
And this can prove
additional aspects of service
to service authentication.
For instance, it can provide
simpler and more secure
means to manage
service credentials.
Zotkix can now add IAM bindings
that allow a native Kubernetes
workload identity to exercise
an actAs permission on the GCP
service account.
So Zotkix can create
a GCP service account
and use that to grant access
to specific permissions
and resources, and then,
allow their workload
identities the ability to
impersonate the GCP service
accounts.
So by doing this,
Zotkix achieves security
without burden of key management
because the authentication
of native, or [INAUDIBLE],,
is handled by the Kubernetes'
infrastructure.
So with workload
identity, GCP services
can more easily be consumed
by Kubernetes' workloads.
In addition, it makes it
even easier to leverage
Google managed services, such
as Stackdriver monitoring
and logging, to seamlessly
deliver functionality
in the ISTIO platform.
So tying it all
together, we can see
that in the hybrid deployment,
Zotkix can leverage open source
ISTIO architecture and Google
managed services, such as IAP
and Stackdriver, in a
well-integrated environment
that delivers consistent,
transparent, and audit-able
policy enforcement.
In addition, through
the integration
of work allied
identity with IAM,
Zotkix can seamlessly
consume GCP services
from their GKE apps
with improved security
by eliminating the
need to manage keys.
So now I want to ask Naveen
to continue this presentation
by showing how Zotkix
can achieve their goal
to simplify identity management
in their consumer apps.
NAVEEN CHAND: Thank you, Breno.
So hopefully that gave you
a good overview of ISTIO.
And we're going to continue
on our story and our journey
now, talking a little bit about
customer identity and access
management.
So through the
presentation so far,
we've talked about
identities for employees.
We've talked about
developers, Group Usage.
We also talked about how
services would be protected
and how you can use these
across hybrid environments.
And now we're heading into
the customer and identity
and access management portion.
So one of the
challenges that Zotkix
has was, with its current
solution, many of its people
are stored in local
CIM instances that
are stored and housed in several
different parts of the country.
But when these people
went on travel,
if a customer was accessing
it from a different location
than they were actually
in, they experienced
a lot of high latencies.
So I'd like to introduce
you to Google Cloud Identity
Platform, which allows you
to add customer and identity
access management
capabilities into your apps.
So the Identity Platform
takes the foundation
of Google's extensive and
mature identity infrastructure
and provides them to
developers in order
to allow you to add this type
of functionality into your apps,
protect user accounts, and
scale with the confidence
that we have built
throughout the Google stock.
The platform includes a
variety of capabilities
that allows developers to
select the type of functionality
that they want.
If they need a user store,
it provides a user store.
If you need to go in federate
with identity systems that
exist inside the industry,
such as SAML or OIDC,
it has that capability.
And lastly, it also
supports a multitude
of different social
auth providers.
Now, one of the great
things for Zotkix
is because it's like Google
and Google scale, whenever
a person connects and regardless
of where they're connecting to,
they actually get access onto
the Google connected instance
of this closest to them.
And so they would be
able to get much reduced
latencies for that initial
authorization request
on the Zotkix infrastructure.
One other thing to note
about the Identity Platform
is it was formerly called
Cloud Identity for Customers
and Partners.
It has now been renamed
to Identity Platform
and is currently in
[? GA ?] as of today.
So we encourage you to
go and try that out.
So just to wrap up, we talked
about the different things
that Zotkix achieved.
They were able to onboard
their users to GCP,
protect their
sensitive accounts,
securely manage policies,
using many of the techniques
that we talked about
from the IAM portion.
Enable seamless access to
the disputed sales team
through tools like,
Identity Aware
Proxy and the BeyondCorp model.
Administer AuthN and
AuthZ consistently
across their environments,
using tools like ISTIO.
And then finally, simplify the
complexity of their Customer
Portal using the
Identity Platform.
[MUSIC PLAYING]
