Enhanced Cloudflare Access: private hostnames, IP apps, and reusable policies

Hello, everybody, and welcome to Cloudflare Security Week. My name is Kenny Johnson. I am based out of Austin, Texas, and I'm a principal product manager at Cloudflare, specifically focused on our Zero Trust Network Access products. I am very excited today to talk to you all about an exciting new feature that we've announced in Cloudflare Zero Trust Network Access, and it's focused on better support for private IP addresses as well as private host names. Additionally, I'm also going to cover some work that we did as part of this bigger effort to make policies fully reusable across your different applications that you've defined within Cloudflare Zero Trust Network Access. So before I dive right in, just quickly taking a step back, what products I'm going to be talking about today, it is primarily Cloudflare Access and Cloudflare Gateway. Those are two of our most commonly used products in Cloudflare Zero Trust. So these are products that you would use to allow users access to your private networks and then decide whether or not to grant them access or block them based on things like user identity, device posture, network context, really allowing you to create a Zero Trust style architecture where everything is being validated and you're not granting broad SWATH network access. Excellent. So I'm going to go ahead and share my screen and we're going to do the best thing, in my opinion, to talk through a new feature. We're going to see a live demo of this feature in action. So really quickly, I'm going to tee this up with kind of what I've set up under the hood and then we'll actually look at the enforcement of an access policy sitting in front of a private host name. So to quickly set the scene, what I've got configured, I have my Google Cloud environment. I just have a Google Cloud VM that's running a simple web server on it. You're going to see that once I actually go through and connect, but I'm running a simple web server on this Google VM at a private IP address. Then in Cloudflare, what I've got set up under the hood is that I have mapped that particular, let me jump to resolver policies. I have created a policy that basically says, or let me grab this view, basically says for this particular host name, I want to go ahead and use an internal DNS resolution for this host name. KennyATX.local, that is a local DNS record. If I am not running the Cloudflare agent and I attempt to connect to that, I would just get resolution failed because KennyATX.local isn't a public DNS record. No DNS resolver would know what to do with that particular record. So what did we add to access and what basically, what differed from how users would do this before? Because we did support private host name based policies and private IP based policies. The major change that we made is if I come in here and look at Cloudflare access, what I'm able to define is a policy based on a private host name. So that is the new piece within Cloudflare access. Previously, I could only define access on a public host name. So that's a public DNS record that I've got configured on Cloudflare. Now I can come in and I can add as many private host names and as many private IP addresses as I want to an individual application. So basically that allows me to then enforce access style policies, which allow me to create policies like, let me just go ahead and jump into an example one. It allows me to create policies based on a user's identity, based on specific information about their device, their IDP group, the country they're connecting from. I really have a lot of power in terms of being able to include specific users and then require specific things about those connections. So I could do something like, let me double check that I have disk encryption turned on for my Windows user. So in this case, I'm saying allow all users from Cloudflare, my personal email, as well as the requiring the disk encryption is on before I allow a user to connect. I can then assign this policy to that private host name application. And then just like an access public host name, I will then prompt the user to log in, issue them a session, and then they'll be on their way to accessing the application. So this is a bit different than what we previously had to do. Previously in Cloudflare, you had a bit of a split. So if you had a public host name application, you could define this directly in Cloudflare access. If it was a private application, so either defined by a private IP address, or a private host name, I actually had to rely on the gateway network firewall. And that's because the gateway is the only tool that allows me basically to route traffic from my agent running on my device into my private network. Gateway is what has knowledge of basically, hey, this IP address needs to be sent to this particular VM, or this server, this database, or wherever that service is being hosted. So what this looked like in practice is I had to create a ton of very specific firewall rules. And I had to really rely on specific naming to make it clear what individual things were defined as. So instead of having just a single contained Cloudflare access application, I had to create tons of firewall rules, all either associated to individual apps or groups of apps. One of the other big challenges was that these accesses were also basically folded into the individual records or logs or things like that. And that was a very problematic thing. That basically meant that I had to sift through a huge needle in a haystack for the individual individual records that were being processed, or basically individual access events. So it's every connection event I had to go and look to try to triangulate and find when a user is logging in versus with access logs. Now you see the individual login events for those applications. Awesome. So let's go ahead and look at what this looks like in practice. So if I go to kennyatx.local, which is the application that I had gone ahead and set up, let me go ahead and I will pull this up to where now I can go ahead and attempt to log in. I'll use my one-time pin code option. Let me grab that code once it gets sent to me. And you can see this look and feel for the application is identical to a Cloudflare publicly hosted application, which is the piece that we're very excited about. Now you no longer have to worry about, is it on-ramp via public hostname, private hostname? It should all be the same experience for users. So I'm going to be able to go ahead and sign in. And you can see I've got, in this case, it's just a default Apache web server running at this hostname and this underlying IP address. And now as a user, I'm able to access that application just as if it were a public hostname and access. And you can even see, I can use the same endpoints that exist in access. So I can say, I can do the get identity endpoint. It'll output my full identity. And I'm able to see the things associated with that particular session. I can also do things like, if I want to do a logout event, I can also logout, and it will kick me out of that session as well. So that is a piece that we're very, very excited about. If I go into my access logs and look at recent login events, I will also see this event logged as well. So you can see my login and logout event associated with that particular hostname. So instead of having to like sift through all kinds of gateway events and every single network connection event, I now have a very clear, concise log about when a user logged in, logged out, just as if it were a public hostname in access. The other piece that we're very excited about that we were able to update as part of this work, well, one small point, we also did a massive UI refresh. So things should be a lot more information dense, a lot easier to use, more kind of hyperlinked up a little more easily. So you should see that benefit as well. But the other piece is access policies are now fully reusable. So previously, policies were app scoped. So every time I created an app, I had to create a policy. So that meant I could have hundreds of policies, even if in my organization, I have like, low, medium and high application, high risk applications, and they all look roughly the same. This now allows me to create policies that are shared across all my applications. And if I need to update policy, I can make that change in one place. And it will cascade to all my apps, instead of having to go through app by app and make make updates in the case of like, hey, I want to exclude a specific high risk country or I have a particular IP address I want to block or I need to modify an IDP group that's being used for a group of applications that can all be done now at a policy level. So I'm able to select from existing policies and assign those. And then if I want to make updates or changes, I can go ahead and come in here and create a reusable policy. And then I can see information about which policies those or which applications that policy is assigned to as well. So that then allows me to see that those details. This is also a sneak preview of we we have some work coming with a bulk policy tester that's going to launch here in the next couple days as well. We're very excited about that. So there are some massive changes that have come to the access UI, as well as some functionality that now allow you to define access applications by public IP addresses and public host names. So that is all I have for you guys today. Again, thank you so much for tuning in. Please, please keep an eye on the blog for all of the exciting announcements and events that are going on with Security Week. We're announcing tons and tons of cool things for the security community out there at large. So we're very excited. Please stay in touch. Please keep an eye on on the dashboard and the blog as we launch more and more new things. And thank you so much.