Zero Trust Week: New Product Demo — Cloudflare Access

Welcome to Zero Trust Week. And this session today is a product demo on access. I am delighted to have Kenny Johnson here, who I will introduce again in a minute right before his section.

But the context for Zero Trust Week, it's a week we're having all of this week in Cloudflare.

And yesterday it started with the announcement of Cloudflare One, a very exciting announcement that announces a platform for our customers to move to the network of the future.

Cloudflare One is a comprehensive platform to connect and secure companies and remote teams anywhere in the world.

It brings together our Cloudflare for Teams product suite, and that includes the product that Kenny is going to talk to us about today, Access.

It also includes our Gateway product, and it includes our browser isolation product, which we're announcing a beta of later this week, also making that available to our customers.

And it brings those products, which are Cloudflare for Teams together with Magic Transit and Cloudflare Network Interconnect, so that our customers can use our network, connect to our network no matter where they are in their Zero Trust journey.

So it's really exciting. So I will now stop sharing this screen, and we can see Kenny there.

So Kenny is the product manager for Access, and we're going to have a great session today where Kenny is going to talk to us about the announcement this morning, which blog went out on blog.Cloudflare.com for Access for SaaS.

So Kenny, I'll open up to you, and I should just introduce myself quickly also.

I'm David Harnett. I'm director of product management for Cloudflare for Teams.

Kenny, what was the announcement today, and why is it important to our customers, and how does it fit with the current Access capabilities that customers know and love?

Yeah, thanks, David. Appreciate you seeing me out there, and welcome, everybody.

Thanks for joining today. Yeah, so in terms of what's being launched in Access for Zero Trust we're calling it Access for SaaS, and effectively what that is doing is you're now able to actually protect your SaaS applications behind the Access product.

Previously, Access had only been for tools that you self-hosted or had control over the domain.

So now you're actually able to fully roll out Zero Trust access policies and access control around both your self-hosted applications as well as your SaaS applications, so things like Slack or Salesforce.

So really, I'll go ahead and dive in now actually to give you guys an overview of the Access product, how it more broadly fits within the Cloudflare 1 stack, kind of why we built that, and then we'll jump into a product demo.

So I'll go ahead and get kicked off here. That's great. Yeah, let's go ahead. I think a lot of customers know Access for, like you said, for protecting their internal apps and really look at Cloudflare as a reverse proxy.

With the announcements this week and our warp client, which can send all of your traffic to our gateway product, but also Access for SaaS, we're really opening up our capabilities now to providing policies for external applications as well as security policies for the Internet.

So Cloudflare for Teams goes from protecting your internal apps to all of your applications and the open Internet.

Also with warp clients, we're now able to connect directly to devices that are, of course, in people's homes right now, which really opens up those capabilities.

I'm really excited to hear about this announcement today.

So I'll hand it back to you, Kenny. Yeah, absolutely.

I appreciate that piece. I couldn't agree more. This is a massive step forward for both Access, Gateway, as well as the overall Cloudflare 1 product offering.

So in terms of what we'll touch on today, I want to quickly set the scene for kind of why this trend emerged, why we went out and wanted to build Access, how Access and Gateway really help.

I'll touch on specifically how Access for SaaS works, and then we'll jump into a product demo and actually set up Access to protect a Slack account.

So I'm excited to show you guys that in real time. Excellent. So if we kick off here, I always like to start off with, if we look at how enterprise networks looked about 10 years ago, it was really this kind of castle and moat idea in terms of, I probably have my main office or headquarters, I might have a data center, and then I might have branch offices.

What enterprise security teams did is effectively built a moat using MPLS connections and then VPNs to create Access into these hardware centers.

They effectively tried to bring the entire corporate network off of the public-facing Internet to protect internal applications and data.

This worked out decently well when everybody was working in offices, when folks were not accessing things from their mobile phones, and when things were not on either public clouds or SaaS applications.

If we look at how things have evolved today, there's kind of three major drivers that have really changed this landscape.

One is the emergence of public clouds, so things like GCP, Azure, and AWS, as well as the emergence of SaaS tools.

Many enterprise applications are now actually SaaS tools, so things like Salesforce or Microsoft 365 or Workday.

These are things that are core business applications for enterprises that are on the public Internet.

Really, the final piece is this bucket of mobile workers has vastly expanded, not only with the emergence of mobile devices being used, but also COVID has really forced this shift to now everybody...

Most of these headquarters are sitting empty and folks are having to work from home, so the load that's being put on VPNs is massive, as well as the noise that's created in terms of the number of inbound connections from your VPN is likely massively expanding, so it's much more difficult to sort through what's legitimate traffic versus what's malicious traffic.

That's where we really took a step back at Cloudflare and realized that we could be a massive help in this situation.

We're already processing a significant amount of network traffic across the Internet.

We have a really good idea of what's malicious traffic versus what's not malicious traffic, so this is where we saw really an opportunity to be helpful to businesses in terms of implementing Zero Trust by sitting in between their data centers, offices, and users with their resources that either live on the public Internet or SaaS apps or are self-hosted applications.

Awesome. Why haven't other companies, other software companies, provided a replacement to physical security hardware like you're describing here?

Yeah, so it's a great question and it really comes into the fact that there just hasn't been a company that's been able to provide the scale and performance needed to provide this level of security.

If you think about how a traditional SaaS software company works is they're likely going to be hosting out of a single public cloud instance or their own data center and that becomes a big problem.

If you're trying to implement security, latency becomes really important.

Users are going to try to circumvent if it's taking multiple seconds for things to load, whereas what we've actually been able to do is piggyback off of the edge network that we've already built here at Cloudflare for our other products and deploy our security products at the edge so that we're able to make security decisions in real time in the blink of an eye without impactful latency that's affecting users.

So this is really something that just wasn't possible until we got to this point where somebody had a distributed enough network to be able to supply this stuff close to users as opposed to with hardware.

It was easy because you could just deploy hardware in physical locations close to your employees and that solved the latency issue, but there's a load of other issues that you run into if you're having to deploy hardware yourself.

Excellent.

So now if we take a look at how Cloudflare 1 comes into play really with kind of a modern Zero Trust or security architecture, this is kind of a basic overview of how this is set up and works.

So we have our CNI product that works with data centers, our Magic Transit product that works with offices, and then our warp client that's actually able to be deployed out to end users.

All of that is able to then be intelligently routed using our Argo product.

And then where we're focusing today is the traffic that is then being pushed to our internal resources.

We're able to filter that with both our gateway products, so doing things like URL filtering by specific user, as well as authentication and access control with access.

So being able to set up specific and granular rules to make the decision of who gets access to which particular resource in which particular scenario, depending on where they're at or which device they're using, things like that.

Yeah, it's great to see access in the picture there with Cloudflare 1 because our customers are asking us for one pane of glass.

They're asking us to have all their logs in one place.

They're asking us to have their policies in one place. They're asking us to run our code and our products in one place.

So our network with our 200 plus cities where we have data centers runs all of these components all together.

So when we are inspecting traffic, we're inspecting traffic once. We're looking after the performance of our customers' traffic.

We're doing it all in one place.

We're giving customers on ramps to our network from their data centers, offices, and also from their devices as you laid out here on the left side of this diagram.

So it's really something where otherwise this could be a multi vendor, very confusing, very insecure in that there are lots of seams between the vendors.

And Cloudflare 1 just allows us to bring it all together and make that journey just so much simpler for our customers.

And access being really at the core, like identity and authentication being at the core of user security.

It's really exciting today to see going from this picture here where we've known access before as internal apps, and now we see it as this really comprehensive solution and a core part of Cloudflare 1.

So that's awesome. Yeah, I couldn't agree more. And it is just, I think the beauty here too is since it is just a comprehensive solution, it's not only can you eliminate seams, but it's something that you can take on over time.

You can adopt access first and then work to adopt other products moving forward.

So it's not a massive long implementation that you have to take on. You can take these things in chunks as you're ready to start to implement these things within your business.

So jumping into access itself, just kind of setting the scene for the access product overall before we jump into our product demo and talk about access for SaaS.

The basic way that access is created is it's meant to sit in between any of your corporate applications.

So either SaaS or internal applications.

And what Cloudflare does is it interacts with any identity provider that you've set up.

And you're actually able to set up multiple identity providers as well as endpoint protection.

So what you're able to do is access controls entry for both your partners and internal employees.

When one of them attempts to authenticate, it's going to reach out to whichever identity provider that user selects.

And then we're basically verifying with the identity provider, is this a valid user?

Does this user match the identity that they've provided? Cloudflare runs additional checks, things like country and IP range and certificate, if you've set those up.

And then if it's a valid user, we issue a web token to that end user, and then they're able to access their application.

And can you answer the question that a lot of customers have, which is they say, we're using Okta or we're using Azure Active Directory, and they may not be as familiar with these types of Zero Trust solutions that access provides.

So they say, why do I need access on top of Okta or Azure Active Directory?

Can you explain the difference there and how you would answer that question for our customers?

Yeah, 100%. I think there's really two core reasons why it makes sense to consider layering access on top of something like Okta or Azure.

The first reason is security. The second is just basically the ability to be vendor agnostic.

So in terms of security, what access is able to do is apply additional security layers on top.

So if you think about your identity provider, like Okta as the actual passport issuer, we're acting more as the actual border guard.

So in terms of what we're able to do is we can add additional context around that passport.

Maybe you're not allowing specific folks in from a specific country at this given point, or maybe you want to disallow that passport due to its IP range, or maybe it doesn't have the right certificate.

What we're able to do is basically layer on additional rules on top of what Okta or Azure might be providing just in terms of baseline security.

It's much closer to that Zero Trust model of don't blindly trust users specifically based on their identity.

The other reason is just in terms of being able to be a little bit more vendor agnostic.

We see this as really useful in the cases of either working with contractors where you don't necessarily want to have to set them up with an Okta or Azure or something like that.

You could just set up GitHub or LinkedIn and allow them to authenticate that way.

As well as if you've ever been involved in an acquisition where the other business is using a different SSO provider, that is much less of a hassle.

You can just plug both of those systems in and then you're able to seamlessly provide logins via both Azure as well as Okta as you slowly move to migrate towards one or the other.

You don't have to rush that, which we often find is the case when a business is acquired.

That's great. Well, I'll let you get on with the demo, but we just have a question here that I'm going to answer quickly.

The question is, hey, Kenny and David, nice demo. What plan do I need to access these features?

So you can use, if you go to Cloudflare.com forward slash teams, you'll see the access product, the gateway product, and our team suite.

You need to use the team standard, which is $7 per user per month. You'll get access and gateway together there, or you can use access as a point product by itself.

And that's the access $3 per user per month. Both of these are over paygo, which is our pay as you go.

If you would like to have a enterprise contract at where you will get support and you will get a log push and lots of other really great features for larger deployments and for enterprises, and you'll get all of these features included there.

But access for SaaS is something that's available in all of our access seats.

We're adding that capability to access. So if you already have paid for access, you get access for SaaS.

Okay. Let's go on with the demo, Kenny, or other slides that you may have.

Great. Okay. Thank you. Yeah. So just jumping in quickly that again, we've touched on what we are excited to announce today.

We're really excited to announce access for SaaS. Basically the way that it works is we actually are able to sit in between any of your identity providers and your SaaS provider, and we supply an access login page that then jumps them out to any identity provider that you've set up.

I won't belabor this because you'll see it in the demo.

So with that said, I'm going to go ahead and jump into the Cloudflare dashboard and take y'all through an overview of how the access product works.

So just double checking, David, can you see my screen okay here? Yeah, absolutely.

Perfect. Okay. So just to set the scene, what I'm going to take you all through, I'm going to talk a little bit about how the authentication works within access, setting up multiple identity providers, and then we'll actually go about setting up Slack as a product within access.

And then we'll take a look at some of the logs that are generated off of the back of that when I go to log into Slack itself.

Excellent. So just setting the scene here, I'm in the Cloudflare for Teams dashboard.

I'm in the access view. I'm on the authentication page.

This is really the spot where users start when getting set up with access. What I always advise folks to do is come in and set up any of their identity providers that they'd like to use.

So in this case, I have Google set up. So that's just any user with a Gmail account is able to use this.

And then the other one that's kind of a neat feature, it's called one -time pin.

And what one-time pin allows me to do is I can grant temporary access to somebody who's not necessarily set up in my identity provider.

And what this does is it basically just, it allows them to put in their email and then we send them a one-time pin.

And by the fact that they have access to that email address, they can access the pin and it's how we use, basically how we validate the identity of that particular user.

And we work with a number of different identity providers.

These are all of the providers that we have out of the box.

If you don't see your identity provider listed, it's likely that we still work with them and we can set them up either through OAuth, using OpenID or through SAML.

These are just the kind of the industry leaders that we typically have worked with and have them in a slightly kind of more catered flow.

Yeah. You mentioned earlier, Kenny, how we work with so many different identity providers.

Here in Cloudflare, we use we use Google and Okta and we can use them together with access really seamlessly.

But it's a very common scenario with our customers that they have contractors, which you mentioned earlier, and they're saying, do I need to onboard them to my Okta licenses?

Do I need to onboard them to Microsoft Azure Active Directory?

Or can I just use something like GitHub or LinkedIn? And that's a really, really common scenario that this enables really seamlessly.

Anyway.

Yeah. And super common even with Slack, because Slack allows for guest accounts and it's really common to have to bring in a contractor or a partner or somebody like that temporarily.

So instead of having to worry about putting them into Okta, you can just say, hey, just use your GitHub account and I'll set you up and then you'll get access to your Slack account moving forward.

So it's just a really easy way to, in a Zero Trust mindset, still grant them access in a seamless and straightforward way.

Awesome. So if I jump over to applications, the way that we think about applications within access is this is any resource that I want to protect behind access or basically that I want to do an identity check before a user is able to access.

So currently, what I've got set up in here is I just have a blog that I host on GoDaddy that I'm actually protecting.

So the other thing to call out here is you can actually protect sub routes within an application as well.

So for whatever reason, I'm protecting my about page on my blog a little bit more stringently than my overall blog.

So I'm able to really flexibly set up and configure these policies around who gets access to which view.

Cool. So now I'll take you guys through setting up access for a SAS application.

So I'm going to come in here at an application.

I'm going to select access for SAS. And then I'm actually able to then select which application I want to be able to set up.

In this case, I've got we've got a number of different applications in here configured that we're able to integrate with natively.

If it's not listed here, you actually should be able to integrate as well as long as they support SAML.

So in this case, I'm going to go ahead and set up Slack.

And then there's going to be two URLs that I need to grab for access to be able to speak to Slack.

If I jump into my Slack account here, I'm going to say, OK, I want to set up a SAML authentication.

And then I'm doing a custom SAML setup, which is very common.

It's what what Okta does.

It's what Azure AD would require. I'm going to open this doc that Slack provides.

And then this provides the two URLs that I need for access to be able to speak to Slack.

So I'm just going to grab those two guys and drop them in. And then I just need my domain.

Which is up here.

Great. So these are available. Sorry, Kenny. These are available because SAML is standard and Slack provides the capability for IDPs like Okta to do this in a custom way.

But the benefit of doing them with us and not directly with Okta, can you just tell us a little bit about that, Kenny, why you would want to integrate these SaaS apps with us rather than with Azure AD?

And directly with an Okta or directly with an AAD?

Yeah, great question. And I think a big reason for that is just that you just have to do it once.

So I just have to set this up one time and then all of a sudden I become identity provider agnostic with Slack or any of my other SaaS applications.

So I set it up one time and then I can really just kind of pick my poison in terms of I can switch LinkedIn in on with just a click of a button.

I can turn on Google. I can put standard Azure AD up and I don't have to worry about going and updating this across all my different apps.

Excellent. Thanks. Great. So I've done the configuration side for access.

Now all I need to do is set up a policy rule. And this is basically, I just need to now be able to define who gets access and who doesn't get access to my Slack account.

I'm going to set up a really basic rule here, but speak to some of the more sophisticated rules that you'd be able to set up.

In this case, I'm just going to allow my internal employees.

I only want to allow Cloudflare users. So I'm going to say, all right, I want to allow anyone with an email ending in at Cloudflare.

So pretty straightforward rule. It's just any time that somebody comes to my Slack login page, I'm going to check that that user has an email address ending in at Cloudflare.

Quickly looking at some of the additional rules that we can provide.

It's things like country. So I can federate which countries that I want to allow in or out.

Oftentimes we see people create embargo lists of countries they want to allow or disallow.

I can add ad hoc emails. So if there's a specific contractor or somebody with an outside email address, I can add them.

IP ranges. So if you have office IPs or something like that, you want to include or exclude.

Everyone is just a basic check to see, does this person belong to this identity provider?

Yes or no. And then these items down here, common name, valid certificate, service token, and access service tokens.

These are for kind of, if you want to take a more sophisticated and secure approach and actually get to where you're putting security certificates onto people's machines.

And what access is able to do is it's able to check and see whether or not somebody has a valid certificate.

So if you have something that's highly sensitive, this can be a great step to ensure not only is the person's identity correct, but is the machine a valid machine that they should be using to access this particular resource.

It's also worth calling out that we're able to do MTLS as well as device posture checks through Tanium to check to see, is this actually a machine that's in good health that we want to allow it?

So there's a lot that I can do with these rules. The other piece I'll call out is we also support Okta groups and Azure AD groups as well.

So I'll go ahead and create this policy.

And then there's three URLs that I need to bring over to Slack.

This is basically just giving Slack the API endpoint that it needs to call, the entity ID, and then the public certificate.

And then I'm going to say I want to enforce that all members go through my access sign-in with Slack.

I can edit this button label.

And then when I save this configuration, it's actually going to take me to a page to test this out.

I get kicked out to this Cloudflare access view.

I can either request a pin or log in with Google. I'm already logged into my Cloudflare account, so this should work and let me through.

So that took me through.

You can see my authentication settings are verified and enabled. And then to really take this home, I'm going to go ahead and jump over to my Slack instance here.

I'm just in Slack. Hello. I'm going to go ahead and sign out of this and then sign back in through access.

So I've signed out. I'm going to sign in with access.

It's going to take me out to the same view. I'll sign in with Google. It'll verify that I'm logged into Kenny Johnson at Cloudflare, whatever my email address is.

That's not my email. And then it drops me into Slack here. That's awesome. That's awesome.

So just exactly the same way as if you had set up an internal app and you put access in front of that and use your IDP and you integrate all those great features that you talked about, like geo or device posture checks, you can do exactly the same thing now and sign yourself into Slack or any other SAML supported SaaS application.

Yeah, exactly. That's awesome. And the real, really the big payoff here is now I have a centralized place to track all of these different access requests.

So now if I come over into my team's dashboard and look at access logging, just save this guy.

So now Slack pops up here. If I look at my access logs, I'm now able to see that access request that I made from my user to that SaaS app to Slack.

So you can think about how valuable this starts to become if you have multiple SaaS apps across your organization.

You're able to now centrally see requests to both your SaaS apps as well as to your internal applications, both who is allowed, where did that come from, as well as if anybody was blocked, you can actually see those block decisions as well.

That's great. That's great.

So we've got less than a minute left, but you've really brought us full circle here on this demo from setting up the IDP to setting up Slack to confirming that you're able to log into it.

And now back to the logs and we can actually see a log that was updated a minute ago.

So that's awesome. In the last 30 seconds or so, anything else, Kenny, to say about this before we wrap up?

No, I don't think so.

I mean, we're just really excited for this to be rolling out. We think it's going to be a big step forward getting to work along with our gateway product and the broader Cloudflare 1 offering.

That's great. Really excited to bring it to market.

Thank you. Thank you very much.