Maximizing Your G Suite and GCP Investments with Google Identity and the Okta Identity Cloud

Speaker 1:  I'd like to introduce our speakers today. Zach Ontiveros is product manager of the Cloud Identity Team at Google. He's bringing his passion for security to the stage today. He's focused on bringing best in class security, identity, and access management systems that Google uses internally.

Also, Steven Lee is joining us. He's Okta's Senior Director of Business Development and Partner Solutions. Lee's ISV integrations with our partners and works closely with Google. 

Thank you. I'll hand it over to Zach.

Zach Ontiveros:  Alright. Hopefully everyone can hear me alright. Everyone's awake. Everyone's excited. Alright, great. Just before I start, quick show of hands, how many of you are existing GCP or G Suite customers? Alright, great. Do another one ... G Suite, only? And GCP, only? Anyone GCP, only? No one GCP, only? Okay, great. 

Today I'm going to be talking a bit about Cloud Identity. If you're a G Suite customer, you should be very familiar with what I'm going to be talking about today. I'm going to give you a sense of what Cloud Identity is, why it's important to us, and really where it fits into our Google Cloud story. Then, we'll talk about you can extend Cloud Identity with Okta to fill in some other use cases, as well as using Okta as the IDP with Cloud Identity. Let's get started.

First, how many of you are non-business Google users? You use G-Mail, maybe?  You use Docs, or you use YouTube, or something? You have an account signed in. We have one account, right? That underlies every single system at Google. You log in once, you have one session, and you can access every application. Because you have such a great amount of data access, it's really important that that one account stays super, super secure. At Google it's really, really important to us that that account stays super, super secure. We put a lot of investment into improving security systems, into security research, into doing the cutting edge, and pushing pen testing ourselves constantly to make sure those accounts stay secure.

We control that entire stack. We know that there is no vulnerability, or hopefully vulnerabilities, anywhere in the stack there. We have our own custom hardware that runs in our data centers. We have our own custom versions of the operating systems that underline our data center servers. We have one of the largest networks in the world that connects between our data centers. Obviously, we run the applications ourselves. It even goes as far as deep Android integrations to be continually scanning the security posture of your device.

Beyond the supply chain, we're also heavily investing in a lot machine learning to make sure that we can catch actors, proactively. Right? We don't want to be reactive all the time. Find out that there was an attack and then have to figure out what happened, afterwards. We're there, trying to make sure that we can catch it before it affects you. 

A great example of that is our Spam system, inside of Gmail. Right? I don't know if you guys use Gmail. When was the last time you got a legitimate Spam message inside your inbox? It just doesn't happen anymore. It's a lot of the ML models and research that we're doing that underlies that. 

We're always looking forward to tomorrow. Right? We're already working on quantum resistant encryption to hit as many buzz words as possible. We understand where the cutting edge is, and we're pushing ourselves towards it.

Given that, given our commitment to keeping consumer identity secure, what is Cloud Identity and where does Cloud Identity fit into this? If you are a G Suite customer, you should already be familiar with a lot of the identity management features that we have available. Right? When you think of G Suite, you really think of collaboration. You think of Gmail drive docs, etc. But for a lot of these businesses, it might be the first time that you went into the Cloud. Right?  You need some level of a Cloud Identity provider to underlie the access and security for these new Cloud accounts. 

We put a lot of effort over the years, trying to keep those accounts secure. Right?  You have things like multifactor auth. You have things like SSO. We want to make sure everyone has a least a baseline of security when using our products.

Cloud Identity is really ... We realize that there's an incredible amount of value here. Obviously, you guys think there's a lot of value in an IUP, that's why you're at this conference. We wanted to make this feature available to all of our Google customers. Right? 'Cause this feature's only available for a staying a paid G Suite customer. 

Cloud Identity is, is taking the best identity management features out of G Suite and making it available as a free standalone offering, for all of our Google customers. 

Back in June, we launched for our G Suite customers, you can now add Cloud Identity, or enable it, inside your admin console to manage, say, your non-G Suite users. We also made it available as a dedicated sign up flow for our GCP customers. They can control their developers access to Google Cloud. So not only securing their access to their servers, but the data of their customers, who store them on Google Cloud.

As I said, it goes beyond just G Suite and GCP. Cloud Identity is really that identity fabric now at Google Cloud. Right? It underlies Android for work. It underlies Chrome. Really it's not just limited to Google Cloud. You can imagine customers who traditionally were analytics customers or AdWords customers that were using, say, consumer accounts, previously, to access those services. Now, you have a more mature Google Cloud Identity offering to secure your access in any Google product.

Let's talk just really briefly. We'll talk a little bit about what can Cloud Identity do, what value does it offer to you?

First, I want to say Cloud Identity is flexible and it's flexible by design. We know we don't want to force every one of customers to move on to Google to be their IDP. Right? It also has the features available, so if you don't have a Cloud IDP or you don't have some other product to serve that need, Cloud Identity is there as a nice base layer for you to get started. 

It also serves as that identity bridge, that managed account bridge into Google. You could bring your own IDP, like Okta, connect it to Google Cloud Identity, and use that to manage all your accounts inside of Google Cloud. 

Breaking down what we see as an essential platform service as ides solution. Cloud Identity comes with the Google Cloud directory. If you're a G Suite customers, you're very familiar with the Admin SDK, as well. Being able to manage your users in groups, set custom profile attributes, etc. 

We also are subscribers of the belief that how you access is just as important as who is accessing. Cloud Identity includes some of the basic device management features that exist in G Suite today. You're able to ... Which actually, I'll talk about a little bit later.

Access is also really important, so user authentication. Google's really big on YOLO. You only log in once. We want to make sure that you have the right connectors in place to SSO and to all of your connected apps. Even more importantly is give that extra layer of security. Be phishing resistant, or un-phishable with MFA enforcement. Most importantly, we're very, very committed to be driven by standards. Right? We want to make sure that the solution that we bring to you is inner operable with all the products you already use and know and love.

Diving in a little bit deeper, I'm going to talk about some of the, what I would say, the key features of the ... The features I'm most excited about inside of Cloud Identity. The first one is Security Keys.

Who here knows what a Security Key is? Hopefully at this point, at this is conference, you're all aware of it. Who here uses Security Keys with their Google accounts? Awesome.  Hopefully next time I ask that question, everyone here raises their hands, 'cause it's a really, really awesome technology.

We are deeply ... We have partnered with the FIDO line, it's actually members of the FIDO lines, to help define what is called U2F, or Universal 2nd Factor.  It addresses a lot of the pain points that you have, with say, traditional, one-time password multifactor authentication.  

Really quickly, how they work, hopefully you guys understand it if you have it deployed out there. For those of you who don't have it deployed, it's not longer that, say I get an SMS or an out-of-band code that I enter in, in which is also susceptible to, say, being phished. Right?  If I somehow social engineer the phone provider, get a copy of the SIM, now I'm able to get the 2nd Factor, just as easily as I can get their password, through, say, a phishing attack.

Security Keys are a physical thing. Right? They're something that you actually have on person. That is attached to the device and registered with the device. Now, what I can do is, I can have this physical Security Key there, and during the authentication event, I can one, vouch for that there is actually a user here. That there is someone, it's not a bot. It's not something else. There's someone here who touched the Security Key and says, "I am here." There is a client server interaction here. I can actually validate that I got the right request from the server. This is the challenge that you gave to me, I'm giving it back to you. Finally, it'll tell you where this request actually originated from. The origin is really important. There's a man in the middle of the attack. Say there's Goggle.com. I'm not paying attention. I try to give the Security Key there. That's not going to work. The server will actually make sure that you're coming from the origin that it expects.

All together, we call this un-phishable. Really, we say phishing resistant, 'cause the second we say "un-phishable" a lot of people try and think, how do I phish this? It really is. It's heavily phishing resistant. It's something Google uses internally to secure all their devices.

Cloud Identity understands that is a really important thing. Cloud Identity actually offers you, not only ... I mean, with any Google account, you can do Security Keys. Cloud Identity goes that extra step. It lets you actually manage your Security Keys, enforce them, and monitor them, and how they're actually being deployed with your user base.

This is a feature that was previously only available in our G Suite Enterprise Que. We believe so heavily in the Security Key framework that we're making it available in the free Cloud Identity product.

The other one I said earlier, is how you access is just as important as who is accessing. Right? The context of where access, knowing whether or not you're accessing from, say, a trusted device or an un-trusted device, or a trusted network, un-trusted network. Making sure you have that full authentication, full access context. 

Inside the free Cloud Identity product, we also have basic device management. It's a little bit of a step below what you have in G Suite today. You have one-click device set up enrollment, and you're able to set screen lock and remote account wipe policy. If that device does get compromised, or might get compromised, you can at least lock them out, give them an extra hurdle to jump. If it does get compromised, you can wipe all the things from the device.

I want to spend a little bit of time now speaking about ... Cloud Identity, obviously, has a ton of value for Google customers. It's crazy to think that this type of functionality was stuck in G Suite before. We're really excited to bring this to all our Google Cloud customers, especially our GCP customers to secure the developer accounts. Where does Cloud Identity fit within that larger story, right? Where does it fit within GCP?

This is a really long quote. I won't read it out to you, but I can give you a second to read it yourselves. Effectively, by raising your hands, who here has heard of our BeyondCorp story? Awesome. If you have not heard of it, I highly recommend you go out and read it. We have a couple white papers out there that kind of talk about how Google today does security.

Me as an employee, I don't have a VPN that I log into. I just have a device that Google has registered. I have my Security Key. I can operate on basically zero trust networks to access internal Google resources. This is a paradigm that we see ... It's pretty much game changing. It's pretty crazy that you'd be able to go out and not have to use a VPN, not have to tunnel into an internal network. You can access all of your Cloud services, securely, from a trusted device.

That BeyondCorp story is really the way we want businesses to work in the future. Google Cloud, Identity, and GCP are providing companies with the tools to help them move BeyondCorp.

Trying to take a step back and understand what this actually looks like. Your traditional employment, right, I'm an employee. I have my device. I have my VPN. I'm accessing on-prem ERP or an on-prem CRM, everything's there. Me, as the network admin or the identity and access admin, I can feel pretty comfortable. I maybe a little worried that maybe my security is only as strong as my network. At least, I have great monitoring, great logs, everything. I have total transparency into who's getting in and out of my network.

As a lot of these SAS Solutions, as a lot these Cloud deployments where people are lifting and shifting traditional corp on-prem workloads into the Cloud, everything's now on the internet. Which you have this great property of, I can access this from anywhere. You also have this property that anyone can access this from anywhere. Let's see what the problems that that brings in.

As employee now, I'm, as always, I can be phished. I can always be compromised as an employee. The device itself may have malware. The device itself maybe compromised. There could be a bad actor on this zero trust network. Right? That's performing a man in the middle attack. At the Cloud border, is the access policy enforceable? In the actual application itself, what vulnerabilities lie in this application that's sitting in the cloud. 

Let's take a look and see how BeyondCorp addresses this and what Google's BeyondCorp story is here. Right? On the left side, we have Cloud Identity here. Right? We have this managed account that either serves as that IDP or has an external IDP, but really it's this managed Google account for accessing Google services. Where you can do Security Key enforcement. You can do endpoint management. You can make sure that, at least, the access event is secure, and you have the context of the access.

Next, you have the Identity-Aware Proxy. This is something in beta that should hopefully be going GA fairly soon. It's basically an Identity-Aware load bouncer that you can put up in front of your services that you've lifted and shifted into the Cloud. We route traffic to it. We do the authentication. We do the validation that this is the correct user that should have access to this application. Then it just passes the jot back to the application. You don't have to go out and do the same application development of defining the authentication interface, making every application do it themselves. You can do this at the central point, which is the Identity-Aware Proxy, which is really, really powerful. You can now centrally control all the rules for access and not have to do the depth time of re-implementing the wheel every single time you want to spin up another application.  

Finally, we have the Cloud security scanner that runs on GCP to make sure that the applications themselves are secure. We understand that there's vulnerabilities at every point. 

That said, I tend to talk way too fast. Really we're here for Okta and Cloud Identity's Okta conference. I want to say, we recognize this is a base layer IDP. This is great for small to medium complexity use cases. We see a lot of value out there and there's a lot of legacy situations that a Cloud-only solution really does not address. That's where we bring in partners like Okta to come in and round out that whole-product story. Right?

As I said earlier, you can use Cloud Identity with any IDP. If you're an OKTA customer you can sync all your identities into Cloud Identity to manage everyone in Google Cloud or you can use OKTA as that identity bridge. Right? You can use Cloud Identity as the IDP, but then use OKTA as a way of authenticating into, say, on-prem systems or other systems with Cloud Identity does not support today. 

Giving you an example, this would be a sample deployment. You have Cloud Identity sitting on the left. You use SAML or OIDC to bridge into Okta. And then Okta's that point where you split out and actually do your authentication events using SAML, OIDC, Kerberos, WS-Fed. Pretty much all the places, all the gaps, which Cloud Identity has today, Okta can fill in and totally round out that whole product solution. 

With that, I'm going to hand it over to Steven. Steven's going to take what I said and hopefully put it into practice. Give you an idea of what this actually looks like, working with Cloud Identity, GCP, and Okta.

Steven Lee:  Thank you.

Maybe, we can stay on this slide a little bit. Thanks, Zach.

There's a lot of synergy between the two companies. I think both Google and Okta, we understand identity. We understand security. We also pay a lot of attention to user experience and admin experience. Right?

I remember going from using my personal Gmail, to using G Suite the very first time. It takes not ramping. You know exactly what you're doing. It's that attention to details around user experience and also building out the flexibility that has allowed us to provide these type of flexibility. This picture here kind of says it all. I know customers that have used Google, started as a small company using G Suite as the master, almost as an HR for them, and then leveraging Okta, getting that information out. As they grow, things change, and you can easily revert it and change and pivot off of Okta and have Google as a service provider and then plug in other services.

A lot of it has to do with the integration that's provided the platform, the APIs. Right? The provisioning API that G Suite has, it's for users and groups, extremely simple to use. It's been an integration that's used by a lot of our customers. 

I was really excited when Google Cloud Platform was launched. To really want to understand how all that is tied together. That's the purpose of the demo today. I think that the great news there is, Google has built GCP in such a way that it still relies on that fundamental Google identity framework that's in G Suite, for you to automate user provisioning, for you to define policies for authorizations and things like that.

With that, I'm going to give you a sort of brief preview or simple demo of how this whole thing works. Let's switch to the other screen, please.

I have two browsers. This is the end-user. Her name is Mandy. She has a typical G Suite account here. Access to G Drive. Now, I have a page here. I'm just going to reload it to make sure that it is real and this little wifi thing is working great today. I'm pretty happy about that. So, right now, you can't see the top URL, but it's basically Mandy trying to access a GCP project called Acme Storage. She's not getting enough permission. How do you actually, now, grant permission for Mandy to have access to this? 

I'm going to switch to the other browser. This is the admin view. There's an administrator here that's running all the systems. This is the typical G Suite admin console that you go in with users and groups. 

This other tab, though, is the GCP admin console. As you can see, there's a lot of complexity here. It's really fantastic. We've got a couple of predefined policies here. If you were to add a policy, what you do is simply add something here. Let me this, give you an example, if I were to type in, "Mandy." Now, that was not a mistake. That was a mistake on purpose. You actually have to have a live entity that's tied to the policy when you're doing this. It has to be a live actual active user. It could be a personal account. It could also be your enterprise G Suite account.

Imagine if I were to do this for each individual user, it'd be very painful. Let me just, kind of, show you, if I were to just change this and type in the real user everything would be actually, it will basically start working again. It was a deliberate typo. Now, I don't have that anymore.

Now, this is kind of the cool bit. It's a very fine grain set of authorization policies that you can do here. It's actually very, very powerful. As you dive deeper into the GCP environment, you're going to have a better understanding of how to use all this. I'm doing this manually. I think the great thing is, APIs are supported to basically do this stuff in a programmatic way. You can imagine, as you're scaling out your environment in GCP, creating more project, deploying more instances of applications and databases, and things like that, you can automate all that stuff. Right? Through scripts or through APIs, so it's a really powerful framework.

I'm not going to complete this whole thing. I'm just going to cancel it. The example I want to show here is the one that I'm pointing at, which is actually a group. It's the Acme Storage group coming out of a G Suite environment. This is basically tied to ... I'm basically granting the owner privilege of this whole project to anyone that's a member of this group. You're moving away from assigning things individually, using buckets of users, and now you've got a group.

How does that work, right? If I were to go back to my standard G Suite admin console ... Ooh, I got locked out. Acme Storage is a group that I've created. The group checks are all active. I could not of put any group that has a bogus name. It's got to be an active, live group the belongs to a Google domain. 

Now, we've got the role that's tied to a G Suite group, so now, you take it back one step. I'm going to the IDP. Looking at in the Okta environment ... Let me take you to the G Suite app. If you look at the G Suite app, we have ... Some of you might be familiar, some of you might now. We've had a push group functionality in Okta, which really allows you to tie an existing group in Okta. Whether it's a local group in Okta, or a group that's coming out of workday, or coming out of AD, tie that to a group that's in a downstream system. In this case, I have actually tied a local group called Acme Storage to a G Suite group. The memberships are in sync. Any changes happening in Okta, that membership will be pushed out to G Suite. Now, you think of where you would deal with the local group membership. Right? That could be managed within Okta, but then you would likely tie that to, maybe, an external system, whether it's an HR system or AD or LDAP. You have a really powerful way of automating authorization for people having access to GCP, but you're also having the ability to monitor access and be able to do audit on it based on information that OKTA has gathered.

What I'm going to do, is just to show you that this actually does work. I'm going to go to the group tab and actually add Mandy into this group. I'm doing this manually. Most likely you're going to have some sort of automated way of doing this or maybe even plug in an approval request workflow on top of this, to make this work.

I'm going to add Mandy. I'm going to hit save. Now, again, there's new integration that we've done. This is the basic G Suite integration via the user and group API. What I just did there basically automatically led to a group membership being pushed to G Suite. Now, if you trace the whole thing back, if I actually go back to the admin console, and actually look at this group ... Now, I do have one user in this group. Sure enough, Mandy is here. What I'm going to do is ... The policy hasn't changed, so now we're going the other way. The group membership has changed. This policy has been in place for a while. I'm going to go back to Mandy. To this page. I'm going to do a refresh. Sure enough, now Mandy has access.

That was a very simple way of demonstrating how the authorization flow. Right? I think it's really important, whenever you look at a platform like a GCP, it's a very complex environment. Right? Who's going to be in that environment? You're going to have developers. If you're in some sort a lift and shift initiative, you're going to have database admins. You're going to have applications admins. Right? 

We've seen situations where managing the authorization and assignment becomes really messy. This gives you, now, one layer of abstraction. I really like the way Google has done this, because it's relying on the existing identity platform and the users and groups. It gives that really nice level of abstraction. 

You're likely going to have a set of groups that you're driving G Suite access with. You can double up on those groups and use those for some of those general things. Maybe there's a group for IT folks. Maybe they can all come in here and do certain things. You can also create a lot of new groups specifically for GCP. Tying that with Okta, now you have an in to in flow of someone potentially logging in with their AD credentials into Okta, then through the authorization, getting access into G Suite, and then flow into the GCP console and then seeing the right things. That's a very powerful thing. 

Of course, the reverse is also very important. Right? To manage users out of the projects and take them out of things that they previously have access to. 

It's actually very powerful. The great thing is, I remember talking to Zach and a couple of the folks thinking that, oh no, there's GCP. We'll probably have to go through a lot more integrations to make this work. We didn't. Everything just sort of worked from day one. I think that's a very powerful thing. Again, big kudos to folks at Google to build it that way. 

Now, a couple other things that Zach mentioned in GCP. Right? Identity-Aware Proxy, and then there's also an API gateway, Google Cloud Endpoints. We've actually successfully done a POC with Google Cloud Endpoints. Again, Google, understanding standards, Google Cloud Endpoints is basically API access management. We've successfully done a POC leveraging, [inaudible 00:26:18] Connect, and OAuth to basically get those API authentication and authorization right through.

The other thing that we're working on is Identity-Aware Proxy. If you think of the nature of an Identity-Aware Proxy, it is sitting in that perimeter. What it does, is really filtering out and figuring out who the user is and then have the information passed down to the relevant applications that are sitting inside GCP, behind the proxy. That's one area that we're working very hard, right now with Google.  As Zach mentioned, the Identity Proxy is still in beta. We're spending a lot of time there.

Would love to hear from folks on, especially people that are starting to use GCP, what are some of the challenges and what are some of the questions? Because it, obviously, is new, but it's a huge opportunity for, obviously for Google, but also for OKTA customers. Right? To kind of figure out how to do things from day one. Do it the right way, without getting into the mess that a lot of other folks get into.

With that, I know we're cutting a little early. Material's a little short. Zach and I will stay here. We'll answers questions, if anybody wants to come up and ask us questions. We'll also be in the expo hall where the Google G Suite hub is. 

With that, I'd like to thank everybody. I know the keynote ran late, but hopefully, you'll enjoy the rest of day two. Thank you.