1️⃣ Access External Evaluation Rules

Hello. Good morning, good afternoon, good evening, depending on where you're joining at from the world or in the world. Welcome to another segment of Cloudflare TV and more broadly, welcome to Cloudflare One Week. It's one of our innovation weeks where we're focused on completely deep diving in our Cloudflare One product, which is our Zero Trust offering combined with our network services. My name is Kenny Johnson. I'm a member of the product team and I'm joined by James Royal. - James, if you want to introduce yourself. - Yeah, I'm James Royal. I'm the engineering manager for the Cloudflare Access Team here at Cloudflare. Excellent. And James and I get the opportunity to work pretty closely on Cloudflare Access together. We've come up with, come up with and gotten to work on a lot of cool new features over the last, last couple of years. So very excited to have him join today. So to kick off, our segment is focused on a new feature that we shipped this week. It's called Access External Evaluation Rules. There's a blog on blog.cloudflare.com explaining this that dropped early this morning. I think it's probably the third or fourth one in the list of blogs. To take a step back to set the scene for this feature, I want to quickly touch on what Cloudflare Access does as a product. Cloudflare Access is a reverse proxy, meaning it sits in front of a website or a hostname or a domain name or a specific path. Basically, it allows you to put Cloudflare in front of that site and then it allows you to enforce Zero Trust policies that are denied by default for that particular application. So without changing any of the underlying code to your application, you can add an authentication and policy layer that looks at things like a user's identity, information about the machine, the location that that request is coming from, whether or not there's a certificate on the device, loads of different context to then decide whether or not to allow or block access to that particular application. And unlike a traditional VPN model where once a user is on the right IP address, they have implicit allowed access to all of your applications, you can granularly configure these policies to say only developers get access to a specific CLI tool or the company broadly can have access to email. You have a lot of flexibility with how you're able to create access and federate access to those applications. And today that gets even more flexible. We have added the ability to now make an arbitrary API call out to any service that you want to additionally check a user whether or not a user should or should not have access to a particular application. So without further ado, we want to show you guys the actual feature. So James has got a demo queued up and we'll talk to you guys through what is involved in setting up this feature, what it looks like, and then talk through some - of the ideas that we've had for for actually using this in practice. - And we're going to just do fun live demos. Yeah, that's the other that's the other caveat is that this is a live demo. Anything can and will happen, so bear with us, - but generally we should be all good. - And you get to see all of my cool tests. Anyways, so what Kenny was saying. I'm just going to show you what Access looks like on a normal basis. So this is my website. If I go to it, I get blocked by Access. I have a lot of IDPs for testing and I like my mustard-colored back here. But if I just want to log in, let's just say Okta, for example, I'll log in and I end up at my website. As part of it, I get an access JWT that says who my identity is. This is pretty standard. This is this is just doing a normal check to make sure that I had one of my email addresses to be able to reach my site. But let's say for some reason or another, I wanted to lock this down so it could only I could only access this during business hours. Before, we didn't offer that as a rule. You can't actually add that to your Access policy today or you couldn't add it to your Access policy today, but now we can. So if I log out again, but if I go over here and I'll show you kind of what my current access policy is, I have an allow service token policy, and then I just have an allow James, so all of my email addresses and my Cloudflare people internally can look at this, but to set up a new external rules rule, you're going to go ahead and... Well, so Kenny mentioned this. You can use any service you'd like. We have created a Worker to make this pretty turnkey just so you can kick the tires with it. If you'd rather write your own service in whatever language you'd like, feel free. You can use this as a template of what we're expecting you to do as far as the API contract is concerned. I think we also define that in the API docs as well. But effectively what, all you have to do is once you clone this down, you'll update the Wrangler file with what you need, which I've done here. So I have my information in my Wrangler file. The key piece is you need to put your cloudflareaccess.com subdomain, you'll need to create a Workers KB namespace and call it KB and then find it here. You don't need a route because Workers.dev will give you one. I'm going to go ahead and just have one. And then basically once you have that in place, you'll open index.js and then there is this little block here called External Evaluation, which is effectively all you need to do to add business logic. Everything else that this flow requires is handled automatically for you. At a high level, what's going to happen when you make when you set up this Worker is Access, when it's doing its policy evaluation, will sit there and make a request from our service to your worker. We do that by taking your identity, wrapping it in a JWT, signing it with our keys, and sending it to your service. Your service, we kind of expect you to validate that JWTC note came from us. You don't have to, but we would highly suggest you do. The worker will do this automatically for you, then it will basically give you that claims. So in this particular case, the identity of the user who's logged in, as far as we're concerned, you can make any choice you want to on it. As an example, right now it's just doing an email check, but that's just kind of what I put in as the default. We'll do one here in a second where we change it to business hours. But what it'll do is you then have to return a success, true or false value along with the nots that we gave you as part of the incoming request. You'll sign that in your own JWT and send it back to us and you have to provide us a keygen point so that we can validate your JWT. This worker will handle all of that for you. It will automatically create the key set. It will store it in Workers KV which is going into that Workers KV finding, then handle all of the JWT manipulation for you so you don't have to deal with that and you're just trying to see what it will do. Anyway, to get to the point, I already just did this, because I didn't want to do this live coding. So, I got a request. In this particular case, I don't even need the claims because I don't particularly care what the identity is. All I really wanted to know is that this request was happening sometime between 9 to 5 or 9 to 6 UTC time. And so all I'm going to do now is I'm going to wrangler publish this worker. That's all it is. It's really quick, it's really easy. The very first time you do this to generate your keys, you'll need to go ahead and make a curl request to the Keys endpoint. So in this particular case, like this. That will generate your keys for the very first time. After that, you don't have to do it, but it is just the way we have it set up. That's kind of one of the first things you'll have to do. And then another thing you can do with this is you can wrangler tail, which is really cool. You get the logs from Wrangler. And so we'll go ahead and do that. And now we're back at the application policy. So as a part of this, I want to now require that you can only log in to this site as part of business hours. So you're going to give it your Workers URL. So in this particular case, it's my domain. And the keys URL which if you use our worker, it's just the same URL slash keys, and that's all it is. It's just a new rule. Tell us where to send the request and where to get the keys to validate it. And we'll save it. Save it again. And now, if I go to log in. Um. I waited one... You made it out here. If we look at our logs, you can see that we actually hit the endpoint to fetch the keys. You can see that we made a post request to the endpoint with the JWT. Currently in my dev, I... Oh, it's because I have it recently redeployed. I had this set to true when I was testing earlier. So you're getting some debug logs of which one of them is the incoming JWT, which you can take... So if you're like, what do I, how do I know what I'm looking at when it comes in? You can take that and go to JSON Web Tokens JWT.IO and you can see that this is what we're actually sending in on the incoming request. So it's my entire user identity from Okta. It's got your device posture rules. It's got whether it was a WARP or gateway request, if there was any service token or mTLS status on it. All of that is included so you can make any kind of decision you're looking for there. And then it also shows you what the outgoing JWT is, which I'll show you real quick just so you're aware of what that looks like. So like I was saying, you need a success. block and in this one case, this one was success is true. And we get an issued at, expiration and nonce so that way the RS service can validate. But yeah, and then I was able to successfully log in. Just to show that this is actually doing something, we'll go ahead and change this and say you actually needed to log in between... before noon UTC time. So we'll go ahead and redeploy that. And... Back... Okay... And we'll go Okta. And this time I got "Account does not have access." Okay. So you can't see it. Anyway... You'll have to take my word for it. One of these days, it'll show up with the log. But that log will basically, instead of here in "success" true, this will be "success" false, which is what Access is looking at when we're doing the policy evaluation. And because your rule said that was not allowed, we then failed the policy. So that's effectively what this feature is. Obviously that block is just a worker or anyone's particular case. It could be any service. You can make that do anything you pretty much want. One of, some of the more obvious use cases is some of the access rules that currently exist are kind of rigid in how they are enforced. So for example, our SAML attribute rule requires an almost exact match. So it's like you're looking for this attribute name and it needs to be this attribute value. For a lot of people, that's all you need to do. It's like you're looking for a specific group name or something like that and so that's fine. Some people have, like I want it to be like they'll have an organization or something like that and they have it could be one of this thing, but I need it to be either a regular expression or something like that. With this new rule type, you can do that. You can take exactly what that would have done, and you can see the entire attribute statement and then actually see and then make your own rule to do whatever you'd like on it. And so, as I said, it's pretty much limitless. You can kind of do whatever you need to do. I think we have a ten-second limit just because we want it to not be able to take forever. But generally, if you need to do any sort of extra evaluation or make another decision like you have your Auerbach own system and you want to check that against it, you can use this rule type for that, where it's basically like, I have this identity, are they allowed to go here? Yes or no? And then you can make that kind of choice on your own... Awesome. Thank you, James. Appreciate you taking us through how it works. And I think you're right, there... it is kind of a limitless future. We're not 100% sure how everybody's going to go take and use this, but we have some pretty common things that have come up. I think, as you mentioned, extending and looking at things like regular expressions against email addresses, being able to manipulate and combine SAML attributes, being able to pick specific things out of a client certificate. What I've heard that's popular is even potentially using an external policy language, like if you've already configured your policy management in something like open policy agent and you want to use that, that's fine now. All you can, all you have to do is just make one external call out. You can evaluate an open policy agent completely and then just return a true or false back to Access. So there's loads of things that you can do here. I think one thing I'll say from a product perspective is we're not saying we're done with the Access policy builder. We're going to continue to expand that out and we want to know how to make that better too. So feel free to reach out, either to your account teams or on Twitter, if there are ideas that you guys have for expanding the Access Policy Builder, let us know because we want to build those into it and we want things to be point and click. This is just a piece to extend and make available for users that want to take Access to the next level or just need something really specific to be able to control access to their their particular applications. Yep. And I think one of the cool pieces is that this uses Workers as well, one of our our serverless development platforms within Cloudflare. We want to make sure that this is really easy to use and we've put out an open source repository with an example of how to actually do this directly on workers. So feel free to to fork that off or put up PRs against it or star it or whatever, whatever you'd like in a GitHub. James I keep a pretty close eye on that as well. Yeah, the repo that I was working out of is the one that's actually out public on GitHub. Effectively I've just toned it down, just modified the block. Awesome. And you'll see... you'll see James did 99.9% of it. And there's one PR for me and they're fixing it, I think a typo or something. So it's mostly James. Gotta' get... Gotta' get those credits. Yeah, exactly. Gotta' keep my little GitHub... Github rectangles green. My once a month Github green rectangle. But yeah, with that, I think we can go ahead and wrap up. I think the last plug I'll say is that there's a blog live for this explaining a little bit more in detail how to get started. It's on blog.cloudflare.com. You'll also see a ton of other Cloudflare One Week content there. Definitely check that out. And if you want to learn more about Cloudflare One broadly, we're here to help as well as if you're thinking about a Zero Trust project, let us know. Reach out. We've got specialists and account team managers ready to go to to have really kind of productive conversations to help you plan that out. So with that, I think we can go ahead and wrap up. Thank you, everybody, for joining and enjoy the rest of your day, afternoon or evening, depending on where you're at. Thanks everybody. Everybody should have access to a credit history that they can use to improve their their situation. Hi, guys. I am Tiffany Fong. I'm head of Growth Marketing here at Kiva. Hi, I'm Anthony Voutas, and I am a senior engineer on the Kiva Protocol team. Great. Tiffany, what is Kiva and how does it work and how does it help people who are unbanked? Micro-lending was developed to give unbanked people across the world access to capital to help better their lives. They have very limited or no access to traditional financial banking services, and this is particularly the case in developing countries. Kiva.org is a crowdfunding platform that allows people like you and me to lend as little as $25 to these entrepreneurs and small businesses around the world. So anyone can lend money to people who are unbanked. How many people is that? So there are 1.7 billion people considered unbanked by the financial system. Anthony, what is Kiva Protocol and how does it work? Kiva Protocol is a mechanism for providing credit history to people who are unbanked or underbanked in the developing world. What Kiva Protocol does is it enables a consistent identifier within a financial system so that the credit bureau can develop and produce complete credit reports for the citizens of that country. That sounds pretty cutting edge. You're creating, you're allowing individuals who never before had the ability to access credit to develop a credit history. Yes, a lot of our security models in the West are reliant on this idea that everybody has their own personal device. That doesn't work in developing countries. In these environments, even if you're at a bank, you might not have a reliable Internet connection. The devices in the bank are typically shared by multiple people. They're probably even used for personal, personal use. And also on top of that, the devices themselves are probably on the cheaper side. So all of this put together means that we're working with the bare minimum of resources in terms of technology, in terms of a reliable Internet. What is Kiva's solution to these challenges? We want to intervene at every possible network hop that we can to make sure that the performance and reliability of our application is as in control as it possibly can be. Now, it's not going to be in total control because we have that last hop on the network. But with Cloudflare, we're we're able to really optimize the network hops that are between our services and the local ISPs in the countries that we're serving. What do you hope to achieve with Kiva? Ultimately, I think our collective goal is to allow anyone in the world to have access to the capital they need to improve their lives and to achieve their dreams. If people are in poverty and we give them a way to improve their communities, the lives of the people around them, to become more mobile and contribute to making their world a better place, I think that's definitely a good thing. My name is Justin Hennessy. I'm the VP of Engineering at Neto. Okay, so I understand Neto is an e-commerce platform based in Australia. Tell us a little bit more about it. Neto is a omnichannel sales platform for retailers and wholesalers. So essentially what it allows us to do is enable the retailers and wholesalers to sell their products in multitudes of sales channels. Tell us about the importance of automation in your business. I came onboard as the lead automation engineer, so I think automation is key to anything in this day and age. Like if you're not looking at ways to automate the low-value work and then put your people in the high-value areas or high-leverage areas, I think you're just going to get left behind. So, as a technology company, obviously, critical for us to make sure that automation is at the core of what we do. When did Neto begin working with Cloudflare? So in the beginning, when Neto was looking to migrate from an old cloud provider, we also wanted to improve our, what we call our go-live flow or our onboarding flow for merchants. And a big part of that was obviously provisioning a website, a custom domain name, and a custom SSL certificate. Requesting and getting granted that certificate in the whole process took two domain experts full time. It was a very lengthy and technical process, which took, you know, could sometimes took up to 2 to 3 weeks. So you can imagine, you know, a customer who's itching to get online, that kind of barrier presents a pretty big problem. So what Cloudflare enabled us to do was to literally automate that onboarding or go-live process to almost a one click process, and it also allowed us to diversify the people that could actually do that process. So now anybody in the business can make that, you know, set a customer live with a very simple process and it's very rapid. So that's where we started. What are some of the security challenges you face in your business and how are you managing them? Any online service has to take security very seriously and it needs to know that security is job zero, so we always bake in thinking and process and tooling around security. So what Cloudflare does for us is literally gives us a really good protective layer on the very edge of our platform. So things like DDoS mitigation, Web Application Firewall Protection, all of that obviously is then translated into a really solid base of security for all of our merchants as well. The security is obviously front of mind for Neto as a business, and online e-commerce presents a lot of security challenges. So denial of service attacks, cross-site scripting. We have automated attacks that are trying to find exploits in our forms and our, our platform generally. So prior to having Cloudflare, obviously we had measures in place, but what we've gained from Cloudflare is a consolidation of that strategy. So we are able to look through a single lens and we can look at all of the aspects of our security for the platforms. And I think it's probably safe to say that now more than ever, a good online strategy is crucial to success. The real privilege of working at Mozilla is that we're a mission-driven organization. And what that means is that before we do things, we ask what's good for the users as opposed to what's going to make the most money. Mozilla's values are similar to Cloudflare's. They care about enabling the web for everybody in a way that is secure, in a way that is private, and in a way that is trustworthy. We've been collaborating on improving the protocols that help secure connections between browsers and websites. Mozilla and Cloudflare have collaborated on a wide range of technologies. The first place we really collaborated with the new TLS 1.3 protocol, and then we followed it up with QUIC and DNS over HTTPS, and most recently the new Firefox Private Network. DNS is core to the way that everything on the internet works. It's a very old protocol and it's also in plain text, meaning that it's not encrypted. And this is something that a lot of people don't realize. You can be using SSL and connecting securely to websites, but your DNS traffic may still be unencrypted. When Mozilla was looking for a partner for providing encrypted DNS, Cloudflare was a natural fit. The idea was that Cloudflare would run the server piece of it and Mozilla would run the client piece of it, and the consequence would be that we'd protect DNS traffic for anybody who used Firefox. Cloudflare was a great partner with this because they were really willing early on to implement the protocol, stand up a trusted recursive resolver and create this experience for users. They were strong supporters of it. One of the great things about working with Cloudflare is their engineers are crazy fast. So the time between we decide to do something and we write down the barest protocol sketch and they have it running in their infrastructure is a matter of days to weeks, not a matter of months to years. There's a difference between standing up a service that one person can use or ten people can use, and a service that everybody on the Internet can use. When we talk about bringing new protocols to the Web, we're talking about bringing it not to millions, not to tens of millions. We're talking about hundreds of millions to billions of people. Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it. And they've also been willing to throw those logs away. Really, users are getting two classes of benefits out of our partnership with Cloudflare. The first is direct benefits. That is, we're offering services to the user that make them more secure and we're offering them via Cloudflare. So that's like an immediate benefit the users are getting. The indirect benefit the users are getting is that we're developing the next generation of security and privacy technology, and Cloudflare is helping us do it, and that will ultimately benefit every user, both Firefox users and every user of the Internet. We're really excited to work with an organization like Mozilla that is aligned with the user's interests and in taking the Internet and moving it in a direction that is more private, more secure, and is aligned with what we think the Internet should be. We have seen malicious foreign actors attempt to subvert democracy. What we saw was a sophisticated attack on our electoral system. The Athenian project is our little contribution as a company to say, How can we help ensure that the political process has integrity, that people can trust it, and that people can rely on it? It's like a small family or community here, and I think elections around the nation is the same way. We're not a big agency. We don't have thousands of employees. We have tens of employees. We have less than 100 here in North Carolina. So what's on my mind when I get up and go to work every morning is, What's next? What did we not think of and what are the bad actors thinking of? The Athenian Project, we use that to protect our voter information center site and allow it to be securely accessed by the citizens of Rhode Island. It's extremely important to protect that and to be able to keep it available. There are many bad actors out there that are trying to bring that down and others trying to penetrate our perimeter defenses from the Internet to access our voter registration and/or tabulation data. So it's very important to have a elections website that is safe, secure and foremost accurate. The Athenian project for anyone who is trying to run an election, anywhere in the United States, is provided by us for free. We think of it as a community service. I stay optimistic by reminding myself there's a light at the end of the tunnel. It's not a train. Having this protection gives us some peace of mind that we know if for some reason we were to come under attack, we wouldn't have to scramble or worry about trying to keep our site up, that Cloudflare has our back.