Best Practices for Identity and Authorization With GCP (Cloud Next ’19)
Articles Blog

Best Practices for Identity and Authorization With GCP (Cloud Next ’19)


[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]

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top