Bring your own logic with a fully programmable, secure web gateway

Hi, everybody. How's it going? Thank you very much for being here. My name is AJ Gerstenhaber. I am the product manager who owns our secure web gateway, along with a couple of our other networking firewall tools and DNS filtering and all sorts of stuff. And I'm here to talk to you all about something today that I am unbelievably excited about, something that has been in the works for close to two years at this point. And my intent is to demo a lot of it for you in real time. I know you've probably seen a lot of tech vendor demos over the years, and you know that they don't all go well the first try. So I will ask you to bear with me, live fire here in case anything goes wrong. But we're going to be talking about the brand new integration between gateway and Cloudflare Workers. Who's familiar with gateway or the concept of secure web gateways, Cloudflare 1, Cloudflare 0 trust? A couple of hands, a couple of hands, okay. So at a very, very, very high level, you all know what Cloudflare does, right? Cloudflare runs a big global edge network that has a bunch of services that are replicated across hundreds of data centers. And one of those services is a secure web gateway called gateway. So this sits in all of our metals, on all of our edges, and we on-ramp traffic to the gateway from a couple of different sources. We have our warp client or our Cloudflare 1 device client. If any of your Zero Trust customers are familiar with that, it basically is a VPN that lives on your device and tunnels traffic up to Cloudflare so that you can interrogate it or apply policy to it for your end user population or whatever. And then we also have on-ramps like our Cloudflare WAN or Cloudflare Mesh where you can send all the traffic from a branch or from a subnet or from a data center or whatever up to Cloudflare and evaluate it in the same way. And then you can also send traffic. A lot of people in the last session that I had didn't know this, but you can also send traffic from our developer platform. You can take the traffic that your workers initiate with fetch requests or whatever it is or your containers initiate, and you can have that egress through your Cloudflare 1 network bindings as well. And then you can apply the same things here. This says coming soon only for this whole functionality. So everything else, you can go ahead and start sending your agents that run on Cloudflare. You can send their traffic through our secure web gateway and give them default deny security policies or whatever. You can do that today. You just can't then do this too because that has a little loop danger in it where we don't want you to get in a place where you're making billions and billions of requests at once. But we are going to release that soon too. So gateway is a secure web gateway that does TLS decryption, that allows you to look inside, like deep packet inspection, look at the request headers in the body to evaluate it for specific or sensitive traffic or whatever else you want to apply security policies to it and apply data loss prevention to it. But most secure web gateways kind of work the same way in that you evaluate the body of a request for something. You see whether or not there is a presence that matches whatever you're evaluating for, and then you either let the traffic through or you block it. And that is not really conducive to the way that the world is starting to move. I've been doing this with customers for seven years at Cloudflare. It's my first five years working to help customers deploy this in their environments. And what I found was that there's a lot of heterogeneity between multiple customer environments. Everyone's environment is special or unique or whatever it is that has some little thing in it that makes it difficult to operate with vendors. And there's always things that people want that we don't have. And we're going to continue building. But the thing that we built now in order to try to allow customers to have the most flexibility that they possibly can is the ability to, instead of just allowing or blocking when traffic matches in your firewall, we're going to give you the ability to send that traffic to a worker that is in your account, your own worker, the code that you write, as a proxy. And then the worker will receive the request from the user or from the agent or whatever it is and then transform it in some way, take some sort of action on it, use some sort of binding, and then forward it off either to the Internet or to the private network that traffic might be destined to depending on how your configuration works. So that's cool for a whole bunch of reasons. And we can talk about why that operates the way that it does. We can get into the mechanics of it. And I think we'll have some time for questions. But this is a little confusing. Bear with me. There's a lot of nuance to the way that you have to understand all of workers and the whole developer platform and Cloudflare 1 and the SWIG. And I think there are very few people who are super comfortable with both of those things. So I'm just going to walk you through some live fire examples. I'm going to show you some policies that I have set up to catch traffic. I'm going to show you the workers that then process that traffic. And then I'm going to show you the output, so what's possible. These are just super basic examples. None of this is maybe conclusive, to say the least. You could do the world's most complex things. If any of you run workers, you know that workers are both incredibly flexible. And for being serverless, there's a lot that you can do that is pretty stateful with a worker. And so let's go ahead and get into some examples. The first thing that I want to show you is this little website that I built to dictate something very clear. But this is context.gerstenhaber.com. That's me. That's my name. This website won't be very useful to anyone else, but you're welcome to go to it if you want to. And this is showing I have traffic going through the Cloudflare 1 client on my device right now. And when it hits this website, it matches a gateway policy that fetches the context of the user on the device. So you can see gateway sends to the worker a whole bunch of context that is specific to Cloudflare. Not only do you get the things like the SNI and the source IP that you would get from any headers, but you also get the on-ramp type at Cloudflare. This is onboarding through the device client. This is the VNet or virtual network ID that the user is connected to, the internal source IP, the policy that matched this traffic that allowed this to happen. And then you also get identity information. You have my personal email, my full name, because those things are attached to my device client. And then device posture checks. Device posture is the ability to use the client running on the device in order to determine whether the firewall is on or whether they're using a certain approved version of macOS or Linux or whatever it is, and it will show you which checks passed as evaluated by our firewall. So to help you understand this a little bit better, this is just for capturing context. We haven't done anything cool yet, but to help you understand this a little bit better, this is the code for the worker that receives and processes that context. And you don't need to take a picture of it. I'm happy to share this with anybody after the fact who wants it, but it's pretty simple to write a little TypeScript or JavaScript worker. The important components of this that we don't have time for a deep dive today, unfortunately, but there's a new export class of gateway middleware that allows you to start using request and context and next to determine how the worker should receive the traffic from your users or your services and then what it should do with the full body and headers once it's received it and then what it should do to next forward it on to the origin service or kill the request or block it in place or do whatever you want. So let's see how this works in practice. This is my personal instance of Slack. Slack is something that y'all use Slack, right? People still use Slack? Slack's cool? Okay. And this is a message between me and my dog, and my dog sent me a picture of my cat, which is very nice of him. But so what I'm going to do is I'm just going to take that file and I'm going to download it. And you see image one downloaded here. But I have a policy set up for Slack. Let me get to my policies real quick. Oh, no, I lost my policies. I'll show you this in real time. But so we go to the Cloudflare 1 dashboard. We go to my account, and you go to traffic controls, firewall policies, and HTTP. If you can tell, I do this a lot. I've been doing this a long time. Then you see a number of Connect demo policies that I have here, and one of them is for TPFL Slack file downloads. So you can see this is a brand -new policy, so it hasn't started processing traffic yet. But if we look at it, it's just when the host matches all these specific things about the request and the user matches my email, then the action is a brand-new action called forward, which is how we decide when traffic gets sent to a worker. And then the worker in question is defined here as Connect Slack downloads. So what that worker does, you get to Connect Slack downloads. You can see that it has an R2 binding to a bucket called files. And if we look at the code for this worker, boy, I hope all of this works. So obviously, whenever you load something this way, it gets a little complicated. But here we have the handle, the request, and the context, and the next. Then if it matches on files for this particular thing, fetching these files, et cetera, then it's going to... Oh, I had this in here earlier. Basically, what it does is it takes the file, it fetches it from the request, and then it stores the file to R2. So you can say, anytime a user downloads anything, I just want to take a copy of that file and store it to R2, just in case the user might be doing something malicious that I need to investigate later. So if we then go to my R2 bucket for Connect Slack downloads and refresh it, there's nothing in there, as you can see right now. Oh, the suspense is killing me. Oh, come on. I told you all that there was danger that this might happen, but I'm surprised that I'm having trouble connecting to the Wi-Fi at all. It's just not loading. R2 object storage, all right, all right. So these are all of my R2 buckets, and you can see here that I have my Connect Slack downloads bucket, and it's still empty, so something must have gone wrong in that process. But we will move on to the next demo, and then by the end of it, maybe it's propagated, and we figured out whatever went wrong. So the next thing that I want to show you is another policy to match traffic related to clawed code. And so this does two very different things. In this policy, you will see the host is anthropic, and HTTP is post, and it's the message's endpoint, et cetera. And what that's going to do, what this worker does, let me find the worker. It's on chatops.gerstenhaber.com, and we do have a lot of examples that we've already uploaded to our documentation where you can see what's happening. And this is a very complicated worker because it does a number of things, but the two things that I want to call to your attention is that, one, it's going to take every prompt and response that your users send in clawed code or in the desktop app or in the web app or whatever it is, just using the API responses from anthropic, and it's going to store all the JSON so that you can review all the chats in real time, but you could do that from anthropic, right? That's not inherently interesting. What it also does is I set this up. Have you all heard of Clef? Are you familiar with Clef? Talked a lot about Clef this weekend. Clef is a decision model that Cloudflare just released off the back of some of the big exciting announcements from Jev and this whole we don't need LLMs, we only need decision models and blah, blah, blah. So I used Clef invoked directly in this worker serving as middleware to evaluate the prompts that my users are doing in real time and determine if they constitute something potentially sensitive against my own policies and then block it and return a block directly in line with the way that clawed code typically works. So let's try demo number two. I've got my clawed code instance up here, and this is my personal account, and I'm just going to say I have a little movie database that I've started correlating on spooky.movie. So we're going to say take my spooky.movie GitHub repo and make it public. Right now it's private because I care about my source code, but what if I just decided that I wanted to take it and I wanted to expose it to the Internet? And so Claude's going to think about that for a second, and hopefully, given my Clef evaluation, it's going to tell me that that's a security violation. Look at that. Security policy violation. This user is not able to elevate or change permissions of GitHub repos because that's exactly what I told Clef to evaluate against. So for any prompt that says that would change the other inherent permissions of a GitHub repo, don't return a response. Block it in place. So this prompt actually never reached Anthropic at all. It was first evaluated in the forward worker. The decision logic was applied at the Cloudflare Edge, and then it was returned in the response schema from Anthropic, so it can be nice and native for your users, and they don't have to think about whatever's proxying their traffic or whatever else is going on, and it can be nice and natural. So when I did that, I also would have logged that. So we're going to go to chatops.gerstenhaber.com, and we should see. Oh, that was unexpected. We shouldn't see that. Please let me have access. Okay. So we should see a brand-new request from 1243 where, oh, look at that. We have a nice little rebuilt session. Take my repo and make it public, and then it returned a security violation. So this is just an example, right, because you could do something with this prompt and response in any case, but this allows you within the worker to just format the JSON from the prompts and responses from all of the models that you use and store it in some way that is logical and safe and easy for you, and that, for example, is something that is directly in the worker, and this is just a worker that is loaded from R2 that chose it, but you can then store it wherever you want and use it in your security practitioning and whatever makes the most sense. I have one more demo that I want to show you that I also think is cool. I want to show you first that if you go into, here we go, connect wiki screenshots, we should see no storage in this R2 bucket. Maybe this one won't load either. That would be weird, but we have enough time that I'm going to be able to get through this last demo. The last thing that I built that I think is very cool is that with things like unknown domains, look at this. I'm not, that's too bad. We'll give that a second. Things like unknown domains, there can be big security risks in something that you can't inherently categorize, right? But it also may be like a huge imposition to your users if you were just to start blocking everything unknown because no threat intelligence is inherently aware of everything that always exists on the Internet, right? But if you want to find a nice little middle ground, you could set up a policy that basically takes any sort of domains that are categorized as unknown and then just send them through your forward worker. And what I have in this case, let me find my last worker up here, connect wiki screenshots. This is a super simple worker that every time the worker is invoked, we call browser run, which is a headless browser which is integrated with workers, and it independently will go and fetch the domain that the user or the full host that the user requested and then take a screenshot of it and store it to R2 so that you can evaluate it later and determine, well, if this user may have been compromised at this point. Then we did these millions of websites. How are we going to classify where the threat chain came from, for instance? So if we just go to wikipedia.com, and you did see a moment ago that there was nothing in that R2 bucket, then what should be happening now is that everything I do on Wikipedia, because that was how I set up my policy. We're going to check out the Yuan Dynasty. Let's maybe learn about the Mongols and ethnicities in general. I don't know if you ever click through, just click through Wikipedia, but I always find that to be fun. I've never heard of the word acculturation, so we'll take that. That was enough things, I think. But ideally, what should have happened here is that every time the user requested something within this host, the browser run should have fired from that worker that was used as a proxy in the middle of the request and then gone and taken an independent screenshot. Obviously, you saw the performance was still good. This isn't happening in real time. It's not live. And then if we go back and check our R2 bucket and we refresh it, boy, I hope it loads. Oh, look at that. We have a new object there. And that object is related to wikipedia.org. And there's six images in there. And the first one can't be previewed, but we can make it a little bigger. And you see acculturation. Isn't that neat? Isn't that cool that you can just invoke all of these services in line with your secure web gateway and just use the power of the developer platform in order to accomplish basically any security goal? I'm very, very, very, very excited about this functionality. We have two minutes left. I can't believe I made it through all those demos. All right. I hope you all are as psyched about this as I am because I think this is a super cool opportunity to start building some really exciting and novel security tooling. But thank you so much for coming, and hope you have a great rest of your day.