Zero Trust: Internal IPs + Hostnames

All right. Hello, everybody. Welcome. Thank you guys for joining. My name is Kenny Johnson. I'm a product manager here at Cloudflare. I'm joined by Abe Carryl. Abe, if you want to introduce yourself. Yeah, sure. I'm also a product manager here at Cloudflare and I work on a product called Cloudflare Tunnel, which we're going to talk about a little bit today that helps secure and easily connect your infrastructure to Cloudflare, but we'll get into more of those details in a bit. Awesome. And then my product is a product called Access, which kind of pairs nicely with this set of tools that we're going to talk through today. The primary piece that we want to go ahead and cover is the support we've added for internal DNS. Basically this idea of being able to supply and provide Zero Trust controls that are already available for public facing DNS records for your internal DNS. So Abe and I will talk a little bit about how that's now possible, why we built that, why this is important. So without further ado, I'll go ahead and jump in. Just as a quick background or primer, Cloudflare Access is a Zero Trust remote access solution that you're able to layer on top of your public facing applications. This is an application that you may still want to be private, but you have it running on public DNS. I could have something like test.kenny.com that I want to secure and I'm able to apply an access policy. And in those access policies, I can configure things like a user has to come from the United States, a user has to be part of my Okta tenant, and they have to be in an Okta group that's called developers in order to access this particular resource. This worked really, really well. This allowed customers to switch off their VPNs. In a lot of cases, we actually were able to switch off our VPN in a lot of cases for these tools. However, there are lots of applications that are outside the browser. This is things like SSH, remote desktop, MySQL or SQL server, things like that, as well as there are applications that I may not necessarily want to put out on public DNS. They could be applications that I don't want to touch the infrastructure because it's too fragile. They could be applications that are so sensitive that I don't want somebody to even be able to look at my name servers and see those particular application host names. So there's a number of reasons why you may want to put something behind a private IP address or a private DNS record. So back in the day, the way that this was supported was Cloudflare-D. Cloudflare-D is a daemon that you can run typically on your origin server, but you can actually also run it on your client side device. And what Cloudflare-D allowed you to do was create a connection on a specific port for a specific host name. However, this was a bit of a pain. I had to create multiple individual RDP shortcuts or Cloudflare-D shortcuts for each individual resource that I was connecting. We needed a better way to make this a lot easier for the user. The other piece that was really a bit of a pain is we had to build at Cloudflare support for specific protocols and ports. So we had to build support for RDP, had to build support for SSH. It wasn't possible to have something that was extensible in this Cloudflare-D model. Otherwise, we had to fall back to arbitrary TCP, which just really wasn't ideal and didn't support a lot of the use cases our customers were looking to try and use. We had another option, which is great. We have the warp client, which powers our world-class secure web gateway, as well as our consumer public DNS resolver that you're able to put onto your device and proxy your traffic to Cloudflare. This was really, really good news because we were able to leverage the existing functionality in the warp client to trigger and establish connections into private IP addresses and private host names directly from your machine to Cloudflare. So then what this unlocked is not only for your public self-hosted applications, but now for your private applications with IP addresses and host names. This slide actually needs to be updated. Host names are now fully supported, which Abe will show you guys a little bit more in a bit. But what I'm now able to do is layer the same level of control that I have for my self-hosted applications by requiring multiple identity providers, verifying device posture, verifying network context, verifying location context. Is a user coming from the right country? Are they using a verified, managed machine from your company? Are they are who they say they are? Are they in the right identity provider group? All before accessing a particular private resource. If you think about this compared to what a VPN approach looks like, where all a user needs to do is enter a username and password, and they're dropped onto the private network and they have unilateral access to everything. You're now able to create micro segmentation, just like Cloudflare access to provide true Zero Trust support, where you're able to specify exactly who and when they're able to access particular private resources. And you can cut off lateral movement with Cloudflare firewall controls. So what this then looks like is I can configure policies at a network level that say, I want to allow traffic to a specific private IP address. It's routed over Cloudflare tunnel. Cloudflare tunnel is what makes private IP addresses available. I want to allow a specific port. In this case, it's 3389, which is the RDP port in most cases. And then importantly, I want to lock this down to just developers. So I'm actually using my developers group ID from Okta or from Azure AD to make a decision at a firewall level, whether or not a user should or shouldn't be allowed access to a particular resource. However, remembering IPs is really difficult. Most humans don't think in IPs. For the last six months, our solution was you either have to configure DNS overrides, or you need to actually memorize all the different IPs that you might necessarily be accessing. So DNS overrides were a huge band-aid where you had to configure for each individual host, you had to configure the individual underlying set of IP addresses for that particular host name. This is not great. That's not how DNS is meant to work. DNS is meant to be the Internet's phone book to make it a lot easier for a user to be able to quickly access a particular resource. And with that, I want to hand it over to Abe to talk a little bit more about what we did to actually make this easier. And then he'll walk you through the Cloudflare dashboard to show you how this is now possible. Cool. Thanks, Kenny. Yeah. So just to briefly recap, essentially what we've covered here so far is that users have a need to secure applications. And they do that through a couple of different ways. But to cover Cloudflare access again a little bit, essentially what you're doing is you're putting a Zero Trust policy in front of your application that's being evaluated at Cloudflare's or on Cloudflare's network. And then we can enforce identity-based or device-based rules to ensure who has access to those resources. Moving into the model that we just talked about, essentially there are three key components here. We need a way to connect your infrastructure to Cloudflare. And that's where Cloudflare Tunnel comes in. We install a lightweight connector on your private network or on the origin. And this establishes an outbound-only connection from your environment to Cloudflare. And that's great in and of itself. But then we also need a way for our users to then reach that application that's now connected to Cloudflare. And they do that by installing the warp client on end-user devices. So now we kind of have this full pipe connected all the way end-to-end, where users with the warp agent are able to send their traffic directly to Cloudflare. Cloudflare then sees that this traffic is bound for a private application through your tunnel, sends that traffic down your tunnel, and then ingresses into your private network. And there was underlying work that unlocked some other use cases too, right? Didn't UDP unlock some broader things as well? Yeah. And building in UDP support to that end-to-end flow not only gave us support for internal DNS, also gave us support for, let's say, thick client applications like a SQL server, for I'll broadly call it real-time communication. So for things like TeamSpeak or for anything that uses voice over IP, like different things like that where they're generally communicating over UDP, are things that we got for free with this, which is awesome. Anything that we can get for free, we're always happy about. So that's the short of where we've gotten so far. Now I want to take a quick second and cover how you actually secure those applications and how we set up the internal DNS piece of this. So for internal DNS itself, we wanted essentially what previously happened is all of your traffic goes to Cloudflare and then Cloudflare says, let me go look up this resource and let me see if it's connected to a tunnel. But there are certain things that you want to have evaluated where, let's say, you go to wiki.mycompany.com. That lives at a private IP and we need a way to go and look that up because we don't have any access to where that address should resolve to. We do that by going to local domain fallbacks, which you can see here, and you can go into your Cloudflare for Teams dashboard. You can navigate to settings in the network. And you know what? I'll actually pull some of this up, I believe, if I can. Yeah. I'll turn the controls over to you, Abe. Cool. Thanks. It's always more fun to do a live demo. If I can figure it out, that is. All right. Awesome. So I think I got it here. Yep. Cool. Thanks, Kenny. So this is the Cloudflare Zero Trust dashboard. You can see some of our analytics in here. And when I said that we'd go and navigate to the Zero Trust dashboard and into settings, you can see that we'll come here. You can see, I guess, as a real quick summary, just to orient ourselves, this is your home analytics page. You can navigate to our secure web gateway policies, to our Zero Trust access policies. But for the purposes of this demo, we'll just come in straight to settings. Then we'll go to network where we're managing these things. And then we'll ensure that we have the proxy able to send UDP-based traffic. So we'll click that right here real quick. And then we'll navigate down to split tunnels and local domain fallback. And specifically here, we're going to go to local domain fallbacks. You can see that I actually already have a demo environment set up, which we probably won't have time to get into today. But the simulated flow here stays largely the same, which is that you can enter in something like demo.internal. You can give that a generic description. And then you just want to point that traffic there so that anything that any request that's made from a user device that's running the warp agent to demo .internal will be resolved through your private DNS server. But that in and of itself is not particularly new or novel. There's a lot of technologies that do this today, specifically VPNs. What really makes this special is kind of when we talked about those three different pieces of the pipe and how you have your tunnel that's connecting your infrastructure and you have your warp device or your warp client that's connecting your users to Cloudflare. The magic is really what happens in the middle, which is applying Zero Trust policies to these resources. And to show that a bit, we'll pop up to access where you secure your applications. And then you can see that I have some already in here. And we'll click add. And when we do that, we see a result for internal IPs and host names. Applications you host internally for, which are managed at layer four. So I could come in here and I could essentially say, and you can see most of this right here right now, I can name this application. I can call this knowledge management or whatever you'd like to call this friendly name. You can then go in and kind of select what your destination IP is. Mine was in the 10 dot range. And then we can come down and we can choose an application for this. So I'll continue to fill this out for a moment. And then we'll go straight through. And then at this point, we'll start creating our policies. So this is a default. We kind of have this pre-populated, which is a default allow rule for knowledge management. We can add a description. We can see that the destination IP is already pre-populated for the application that we just specified. We can choose whether or not we'd like to enforce session management. And then we can go down with block rules where we essentially say that we'd like to block access to the broader group. And this is essentially what you're able to do to enforce these Zero Trust policies to users who are then reaching private resources that are being routed through your private DNS resolver. Kenny, anything that I missed there that we should hit on? I think the big piece is kind of why two policies and why do we take that approach? It's because gateway in and of itself is a typical secure web gateway in the sense of you have to explicitly tell gateway what it needs to do in terms of blocking user traffic. And that's great because you don't want to have the default behavior be block everything unless you really are intending to do that. Because you're trying to do things like protect a user from malware, protect the user from being phished, control which content that they're viewing on their machine at any given time. Whereas if you're using gateway as a method of securing access to a private resource, it needs to function more like access where it's an explicit security model of you need to give access to specific users in order for them to be able to reach that resource. So we constructed this in a way of with an allow policy you can be really specific and you can say it needs to be this particular identity group. And then we create a secondary policy that's a block rule. And you can leave that just as a base block rule and it sits right below that policy so that anybody who doesn't pass the allow policy is then automatically blocked for that particular application. So it's really that Zero Trust paradigm of block everybody unless they're explicitly given access to that particular resource. There was also a bit of a bit of a new feature easter egg in Abe's demo that's exciting. We just shipped that today. We're adding the ability to enforce a user re -authentication session for these resources as well. So you'll actually be able to force the user to have to re -authenticate as often as 15 minutes and as far out as a month. So you have the ability to really enforce that the user is who they say they are on their particular machine. It's not just bound to the connection anymore. Awesome. And I think that's as good a non-sequitur as we could possibly come up with into what's new in Zero Trust and what some of the other things are that we're working on. Kenny, I don't know if there's anything that you want to tease right now. But if not, I'm happy to talk a little bit about the tunnel world and some of the things that we're working on there right now. Yeah. One piece we're really excited about is we hear you guys. We know it's difficult to debug and troubleshoot when users can't get access to particular resources. So definitely keep an eye out. We've got some really exciting things coming down the pipe to be able to track and see why a user was blocked from accessing a particular resource as well as being able to try out rules before shipping them out to production with an access. So we hear you guys. We know it's difficult sometimes to troubleshoot and debug these things. So we want to give you better tools. We want to make it easier so that you can self -serve instead of having to work with our support team and things like that. So that's a big thing to watch out for this quarter. Yeah. And I think that on the tunnel side, I'll say the same. I think that we both hear users, but we also hear Kenny. And Kenny and the access team are one of the biggest users of tunnel. And as such, I think that one of the great things about this feature was being able to dog food this internally. As Kenny mentioned, as we shut off our VPN and moved over to access and then started building some of these tools in tunnel, we saw that the flow that Kenny showed at the very beginning of running Cloudflare Debug on the server side as well as the client side introduced various challenges for different kinds of users and different kinds of application access, I suppose. So one thing that we're laser focused on is making tunnel ridiculously easy to use. And one of the ways that we want to do that is to continue making more ways to A, get your traffic to Cloudflare and then also easier ways to build, manage and deploy Cloudflare tunnels. So we're excited to build more orchestration within the Cloudflare Teams dashboard. That's one thing that we absolutely want to focus on. So as we think about what this looks like in the future, the ability to manage all of your tunnels in one place, have those seamlessly integrated and connected to your access applications or being enforced by your access applications is something that we're actively working on and we're really excited for. One of the other things that I'll briefly hit on as well is that in this model of using or of creating a Zero Trust private network on Cloudflare, one of the things that we learned from customers is that a lot of environments have duplicative or overlapping IP ranges. So whether that's from users and customers going through acquisitions where they inherit a cloud environment that they didn't know that they were going to inherit or just because it's easiest to manage that way and have the same IP assignments across multiple environments. Overlapping IPs was something that became a good problem to go solve and that's something that we're also releasing support for in the coming weeks. So we're very excited to think more about how users are going to adopt that and what use cases that unlocks for them. But to the extent there are listeners out there who are really interested in that solution, definitely reach out and we'd be happy to get you early access to that feature as we make progress over the coming weeks. Awesome. Well, Abe, thank you so much for joining. Always a pleasure to tag team these with you. And thank you everybody out there in the Cloudflare TV space. Thank you guys for joining. Hopefully this was enlightening in terms of getting started with using private DNS. There's in the developer documents, there's tutorials out there, as well as if you have a direct account team, your account teams are definitely ready and willing to help you guys out as we get this up and configured. And we're really excited to hear how this goes for folks. So thank you all so much for joining. We'll go ahead and leave you guys to commercial now and have a good morning, afternoon, evening, depending on where you all are at in the world. Thank you so much. My name is Karan Tiwari. I work as a Lead Architect in Odessa E-Commerce at Falabella. Like many other retailers in the industry, Falabella is in the midst of a digital transformation to evolve their business culture to maintain their competitive advantage and to better serve their customers. Cloudflare was an important step towards not only accelerating their website properties, but also increasing their organization's operational efficiencies and agility. Cloudflare, for example, was not just a TI decision. It was also a business decision. That is, the faster we can deliver the data to our customers, the faster, the less loading time and seconds we can improve our site. And that internalizes it as business metrics. So that the business really understands that performance, that is, a second in the load of a page, is a sale. That is, a loss in customer confidence. So I think we are looking at better agility, better response time in terms of support, better operational capabilities. Earlier, for a cache purge, it used to take around two hours. Today, it takes around 20 milliseconds, 30 milliseconds to do a cache purge. The homepage loads faster. Your first view is much faster. It's fast. Cloudflare plays an important role in safeguarding customer information and improving the efficiencies of all of their web properties. With customers like Falabella and over 10 million other domains that trust Cloudflare with their security and performance, we're making the Internet fast, secure, and reliable for everyone. Cloudflare, helping build a better Internet. We're betting on the technology for the future, not the technology for the past. So having a broad network, having global companies, now running at full enterprise scale, gives us great comfort. It's dead clear that no one is innovating in this space as fast as Cloudflare is. With the help of Cloudflare, we were able to add an extra layer of network security controlled by Allianz, including WAF, DDoS. Cloudflare uses CDN, and so allows us to keep customer control and caching at an improved speed. 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. I think one of our favorite features of Cloudflare has been the worker technology. Our origins can go down and things will continue to operate perfectly. I think having that kind of a safety net provided by Cloudflare goes a long ways. We were able to leverage Cloudflare to save about $250,000 within about a day. The cost savings across the board is measurable, it's dramatic, and it's something that actually dwarfs the yearly cost of our service with Cloudflare. It's really amazing to partner with a vendor who's not just providing a great enterprise service, but also helping to move forward the security on the Internet. One of the things we didn't expect to happen is that the majority of traffic coming into our infrastructure would get faster response times, which is incredible. Like, Zendesk just got 50% faster than all of these customers around the world because we migrated to Cloudflare. We chose Cloudflare over other existing technology vendors so we could provide a single standard for our global footprint, ensuring world-class capabilities in bot management and web application firewall to protect our large public-facing digital presence. We ended up building our own fleet of HAProxy servers, such that we could easily lose one and then it wouldn't have a massive effect. But it was very hard to manage because we kept adding more and more machines as we grew. With Cloudflare, we were able to just scrap all of that because Cloudflare now sits in front and does all the work for us. Cloudflare helped us to improve the customer satisfaction. It removed the friction with our customer engagement. It's very low maintenance and very cost-effective and very easy to deploy and it improves the customer experiences big time. Cloudflare is amazing. Cloudflare is such a relief. Cloudflare is very easy to use. It's fast. Cloudflare really plays the first level of defense for us. Cloudflare has given us peace of mind. They've got our backs. Cloudflare has been fantastic. I would definitely recommend Cloudflare. Cloudflare is providing an incredible service to the world right now. Cloudflare has helped save lives through Project Fairshot. We will forever be grateful for your participation in getting the vaccine to those who need it most in an elegant, efficient, and ethical manner. Thank you. Hi, we're Cloudflare. We're building one of the world's largest global cloud networks to help make the Internet more secure, faster, and more reliable. Meet our customer, Neato. The thing that used to keep me up at night was security. Cloudflare helps to mitigate a lot of those fears. It actually is the frontline for our platform and actually looks after pretty much all of the security as well as helping us on the cost side as well. As one of Australia's leading e-commerce platforms, Neato powers the shopping experience for thousands of online retailers. My name's Justin Hennessy. I'm the VP of Engineering at Neato. Neato is one of the biggest e-commerce platforms in Australia. Our platform receives between 85 and 90 million requests per day. We have about 2,800 merchants on our platform. Single shop owners who are just trying to sell online all the way up to quite large organizations who do multi -warehouse sales. In the landscape that we are now in, with cybercrime being as high as it is, the threats that hit our platform on a daily basis, it's really important to have both internal expertise and really good relationships with technology partners. Neato first came to Cloudflare to streamline the process of securing its merchant sites. Using Cloudflare's SSL for SaaS, Neato automatically provisions and manages security certificates across thousands of its customers' vanity domains. SSL for SaaS is essentially the primary driver why we moved to Cloudflare. We have a very complex onboarding process and part of that is issuing certificates to customers. Cloudflare allowed us to make that a completely automated one-click process. Anybody in the business could onboard and go live with a customer. Soon, Neato found additional opportunities to leverage Cloudflare's platform for enhanced security, performance and reliability. The two major things that we've really embarked on this year around workers and AI bot management. Cloudflare bot management is something that we've just recently turned on. In its first day, we were able to block 2.4 million requests and obviously that has a pretty significant cost effect over time. Cloudflare Workers is actually quite an exciting piece of technology. It's really allowed us to be quite creative about how we solve different problems. I would definitely recommend Cloudflare as a technology vendor because I believe they offer the full gamut of products. You can start very small and then you can grow into their feature sets. With customers like Neato and over 25 million other Internet properties that trust Cloudflare with their security and performance, we're making the Internet fast, secure and reliable for everyone. Cloudflare, helping build a better Internet.