Cloudflare TV

ℹ️ CIO Week: Page Shield is now generally available, Early Access to UDP and Private DNS with Cloudflare's Zero Trust Platform; k8s and Tunnels with Kuldeski Security

Presented by Michael Tremante, Dan Gould, Hannes Gerhart, Abe Carryl
Originally aired on 

In this CIO Week segment, Cloudflare product managers and engineers will take a deep dive into the products and features we launched today.

Read the blog posts:

Visit the CIO Week Hub for every announcement and CFTV episode — check back all week for more!

English
CIO Week

Transcript (Beta)

Hello everyone and welcome to Cloudflare TV. My name is Michael Tremante, I'm a product manager for the Fayetteville product and WAAF.

And today I'm joined by a wonderful set of guests and we're really excited to talk about some of the announcements we've made today as part of CIO Week for who's been following the blog, of course.

We've made a lot of a lot of new additions to our Cloudflare portfolio, and today we're going to try and pack into half an hour updates on three different products that we've announced today on our blog.

And before we kick things off, a little bit of bookkeeping.

Bookkeeping, if you have any questions, of course, please do send us an email at live studio at Cloudflare Dot TV.

We will receive those emails and if we have time towards the end, we'll try and answer them.

Otherwise for sure. We will follow up, follow up offline and get your questions answered.

But I don't waste more time on that.

Let's get things kicked off.

I'm going to quickly give the line to the guests here to make sure they introduce themselves.

And Abe, do you want to quickly talk a little bit about yourself? Yeah, sure.

Thank you. So my name is April. I've been at a Cloudflare for about two years now, which is kind of crazy to say.

It feels like I started just last week.

That's how pandemic time works.

But.

But, yeah. And I work on our product called Cloudflare Tunnel, formerly the artist formerly known as Argo Tunnel.

And I'm excited to talk about some of the some of the new releases that we have today and some of the things that we're working on this quarter.

Awesome.

Thank you very much. Now over to you, Hans.

Nashua.

My name is Hans Gerhart. I joined Cloudflare also a bit more than two years ago, actually, on the Solutions engineering team.

Then after that, I moved to the product team and now I am responsible for our authoritative Das.

Right.

And as we all know, DNS is one of the core parts of the World Wide Web. Thank you very much.

And then final at least. Dan, would you like to give us a few words about yourself?

You bet.

Hey, everybody. Dan here. I joined Cloudflare earlier this year, early in 2021.

I'm on the product marketing team and I support our application security portfolio.

Things like of course like our WAAF is Michael mentioned API shield to keep APIs safe and productive and management.

But today we're actually here to talk about really exciting stuff, so can't wait to get into it.

Perfect.

Thank you very much. So as you all heard, we've got three very interesting topics to talk about.

And I think we're going to kick things off talking about Cloudflare panel. So I'll call you to the stage first.

And before we go into some of the updates we released today, why?

You know, let's pretend I'm new to Cloudflare.

Do you mind?

Give us a quick intro on what is Cloudflare Tunnels? Yeah, sure, I'd love to.

So Cloudflare Tunnel is essentially, I think the really simple way to put it is that it's it's an easy way to connect your resource to Cloudflare.

That resource could be an application or a service or even an entire private network.

And it just essentially allows you to make that from your origin to Cloudflare's Cloudflare network or Cloudflare's Edge.

And I think that the slightly more in depth explanation is that it really helps ensure that all the all the traffic that's coming to your origin is being routed through Cloudflare and things that wouldn't normally be publicly addressable in the on the public Internet.

So yeah, that's that's a little bit about Cloudflare.

Cloudflare Tunnel was originally built as an origin IP protection service.

Now it's a part of our Zero Trust suite and it's a really easy way to make sure that your resources are getting the Zero Trust protection that they need.

And out of curiosity, if I'm a new Cloudflare user, is it is it quite easy to set up a Cloudflare Tunnel from any of my devices at home?

Yeah, yeah, great question.

It is so it's generally not a three step process.

So the first thing that you'll do is you'll install Cloudflare on your on your local machine.

That's our lightweight software or lightweight connector that establishes those for outbound connections to Cloudflare's edge to then proxy traffic to your origin.

But you install Cloudflare Software from there, you then create a tunnel, you'll give it a friendly name so that you can reference it in the future.

You'll add the routing rules that you wanted out, whether those are DNS or load balancers or IPS, and then from there you'll just run your tunnel.

So it's three pretty quick and easy steps to get started and tunnels are free for everyone.

There's no limits on the number of connectors that you have, the number of users who are going over those.

And yeah, it's completely throttled for for any use.

Awesome.

Yeah. And I can confirm that's the case because I have tried myself. It's really cool to set up a website hosted from your laptop just by connecting to Cloudflare Tunnel via Cloudflare.

So we have Cloudflare Tunnels.

And what is what is the new announcement, I guess what is new as of today with Cloudflare Tunnels?

Yeah, great question. So about a year ago, we launched a new feature within the Cloudflare Tunnel world that we kind of internally call Cloudflare Private Networks.

And what that allows you to do is to is to instead of doing things at how tunnel kind of previously work on a 1 to 1 relationship and then we grew that into a12 many relationship.

It allows you to connect an entire an entire private network range to Cloudflare by specifying the route and the CIDR range that you'd like to connect.

What we're announcing today is within that kind of feature, set the ability to proxy UDP based traffic as well, which will unlock a variety of new features, things all the way from.

Let's say that you and your friends want to run a local gaming server, you want to connect over Minesweeper or something like that.

You could do that all the way to more complex use cases like private DNS and kind of pointing that at Cloudflare as well and being able to make those connections.

So that's really kind of the the one liner for what we're announcing today and excited to talk about that in more detail, too.

Got it.

And so just to confirm, does the actual set up change from what I did previously when trying to set up a website or does the way it works change a little now?

Yeah, it works a tiny bit.

So when we talked about just setting up your just connecting a single resource to Cloudflare, all you really need to do in that scenario is just have a tunnel.

When we talk about private networking, we want to think about the connectivity from two different perspectives.

One, from connecting both your private network. I'll just bucket that as your resources to Cloudflare.

But then we also want to think about how those users are then getting connected to that network over Cloudflare as well.

So the setup changes a little bit in the sense that you'll still take the same steps to create your tunnel, but now you'll also on the client side or on the user side, they'll, they'll deploy the word client or 1.1.1 application and then enroll into their to their Cloudflare for Teams organization.

From there, they'll be able to send traffic directly to Cloudflare.

Once that traffic is routed to Cloudflare, it'll, it'll, we'll be able to tell that's destined for a tunnel.

We'll route that traffic accordingly to your tunnel and then that tunnel will reach out to your private network.

So just to confirm, my understanding is correct, it's pretty cool.

We're essentially getting the secure in the connection end to end here all the way from wherever the eyeball is with Warp reaches the cloud for edge and then goes back to wherever I'm hosting my services also knew to be traffic with cloud for tunnel.

Yeah absolutely. That's that's exactly and I think that.

But the really interesting piece comes to you when you start thinking about how this applies to a Zero Trust security model as well, and what we're able to do now that we have that traffic coming through Cloudflare we can essentially evaluate policies.

You can create identity based rules, device posture rules. You can create these rules and per resource, per request ensure that the right people are reaching the right things at the right time.

Okay.

So let's say I want to go try this now. Do I go?

Where do I find it? In the Cloudflare dashboard.

Is it still in the same place? Or any changes there?

Yeah.

Great, great. So it's you can find this all in the Cloudflare for Teams dashboard.

That's dash teams, dot Cloudflare dot com. If you want to sign up, you can hit dash to Cloudflare dot com forward slash sign up forward slash forward slash teams.

And from there, you'll be able to get started with up to 50 users for free.

You can navigate and within the Cloudflare for Teams dashboard, we'll have an onboarding flow that should be pretty comprehensive.

When you click on the tunnel's page, we'll kind of walk you through those three steps of creating your tunnel, routing your tunnel, and connecting or running that tunnel.

And then when you go to the devices section of the Cloudflare for Teams dashboard, you'll be able to kind of go through all the different steps of installing the client and going through the installer and logging into your team's org.

So yeah, it should be a pretty, pretty handheld kind of process. But yeah, just kind of two quick steps to get started today.

Cool.

I know what I'm doing over Christmas then. So one last quick one last question for you.

They also want to see this product evolve and get better over time.

Any little glimpses into the future that you'd like to share?

Share with us?

Yeah, sure. I think that one of the things that we're excited to work on this quarter was a problem that we're kind of internally rallying around the concept of overlapping IP.

So a number of customers have virtual cloud environments where by default all of their resources are getting the exact same IP assignment.

And that kind of introduces an interesting problem where the question becomes, okay, if I have two resources that are sitting at 192168.0.1, which one do I route this traffic to?

What we're giving users the ability to do is to create new virtual networks and then from the client kind of deterministically choose where they want that traffic routed to based on the resource that they're trying to reach.

That's something that we're super excited about.

And then of course, continuously in Cloudflare fashion, trying to make it ridiculously easy to use.

So continuing to focus on those onboarding flows and simplify that onboarding process as much as we can.

Well, awesome.

Thank you very much for sharing all of the updates with us. Great.

So in the interest of time, let's switch gears a little and go from Cloudflare tunnels to dance and harness your turn now.

Before we jump into our updates around dance, though, mind giving us a quick insight on for our audience what is what is dance?

Absolutely, yes.

So Das stands for Domain Name System.

And in very simple terms, it's the phone book of the Internet.

So every time you want to visit a domain, for example, by typing in Cloudflare or com into your browser, your machine, your laptop actually needs the IP address, and that's what DNS is for.

So translate domains to IP addresses.

Got it.

Yeah. No, that's it's pretty much at the center of how we use the Internet today.

Right. So as many of you know, of course, Cloudflare has been operating a DNS service for quite some time.

And here's our product manager for DNS services.

But why?

Why should people use Cloudflare's DNS services?

Is there any good reason for that?

Definitely, yes.

And first of all, I would say a good chunk of our audience might already be using Cloudflare for DNS.

So about 15% of all websites on the Internet today is using Cloudflare Name Service.

Think about that number. But I think there are three central reasons why I would advise somebody to switch over to Cloudflare DNS if they're not using us today.

The first one is that it's just ridiculously easy to use.

You can sign up your domain in a matter of minutes, go to a cloud or com and sign up your domain and you're using us for DNS.

It's super, super easy.

The second one is that our audience is literally lightning fast.

And we deploy, deploy our name servers and our global network.

So we are we are our network is the one of the best connected networks on the planet.

So we are very, very close to all those services, the resolvers, for example, who are carrying your domain names.

So that's why we achieve that, to resolve within a low number of milliseconds.

The third reason is that by using Cloudflare for DNS, you get a very high level of reliability and security.

You definitely want your audience to be available in online all the time.

And yeah, Cloudflare has gathered a lot of insights into defending against DDoS attacks, these large volumetric attacks to bring down infrastructure.

And when you're using Cloudflare for DNS, then you are definitely protected against that.

Your name servers will stay online. Yeah, I always found it impressive to think and it's not always immediately obvious if you're using Cloudflare DNS, those DNS records are actually replicated correctly wrongness in every single data center we have worldwide and the end user is doing those DNS lookups.

So show the resolution will start from the root service, but eventually we'll hit the closest to their location.

Right?

So it's like spreading DNS records literally to every corner of the world. Okay.

And in there, in the context of our of our Innovation Week, of course, we're talking about CIOs and security, internal networks, etc., and diving a little bit deeper.

Any reason why CIOs should care about DNS? I think CIOs should very, very much care about DNS.

As I just explained the beginning, it's it's the foundation of the Internet, right?

It's the phone book of the Internet. Every domain name that is used needs to be resolved to an IP address in some way.

So every service that runs on the Internet, for example, your app, right, when you when you call yourself an Uber, I'm just naming the company here.

Your phone is not the one.

The person who programed the app wouldn't put in the IP directly.

They would always put in the domain names.

Right.

So that's just one example. And all the Internet of Things, devices and everything that's talking to the Internet kind of needs to resolve domain names.

And that's that's what DNS helps with.

So as a CIO who is for you is responsible for the infrastructure for the IP of a company, you definitely should care about DNS because if it goes down and we have heard that we thought about that in the in the past for sure, that can have serious consequences, right?

You can lose a lot of money.

You can lose your reputation.

So it's it's really crucial to have your DNS up and running all the time.

Yeah.

As a bit of a joke in the programing world, it's always DNS, right? I actually managed to take down my prior employer's DNS infrastructure once within my first two weeks of joining the company.

So I know that from personal experience and of course today we're announcing foundation DNS.

What are we adding with this new product?

What is what is the news here?

Yeah.

So with Foundation Dennis, we actually want to take our current Dennis offering one step further.

So our, our current offering, which is also there's a free tier as well, mostly suffices the needs of the users.

But there are a lot of large enterprises who spend a lot of time, effort and money to configuring to configure their DNS infrastructure.

They have very high, very complex requirements and demands and specifically those enterprises we want to target with foundation DNS.

So I can talk about three, three aspects of what this announcement contains.

One is we make pricing more simple.

So currently, if you if you sign an enterprise level DNS deal, you typically have to provide three pricing inputs.

One is the number of DNS queries per month.

The second one is the number of domains, or we also call the zones.

And the third one is how many DNS records.

So one record would be typed up that Cloudflare com or API dot com, for example.

And we are saying this is too complicated, right? This needs more simplified.

So that's why we're saying foundation DNS customers are only priced on the number of DNS queries per month.

That's it.

That's as simple as it is. The second one is that we want to we want to provide even higher reliability to our foundation DNS customers, and that's by giving them an advanced set of name servers so they would not use the default, the standard Cloudflare name service, but they will give will get a separate set.

And we'll we're currently looking into all the ways how to make this even more reliable and there will be more updates about that in the next year.

And the last thing is that we will be also working on additional premium features that will be available only for foundation DNS customers.

And also for that, we'll have more announcement coming soon.

Got it.

So just, just make sure I fully understand those. So I think from a product and pricing perspective, we've always tried to keep things as simple as it can be here.

Right.

And so a big part of this is even simplifying even further for our dense customers, how that works.

And just having that single metric upon which we, we, we sort of generate the pricing for the product.

Is that right?

Yeah, exactly.

Cool.

And the second one, the name servers, that's interesting because, you know, already we have name servers distributed globally.

And I'm assuming, you know, we're trying to improve performance and reliability even more for our top customers.

And that's is that going to complicate the DNS set up from an end user perspective or will our customers just be able to opt in and nothing for them to do and it just magically happens under the hood?

Yeah, it won't change anything from the customer's perspective, right?

They will still be assigned the set of name servers, but it might be more than two name servers, for example.

Right.

We might decide three or four or five are just more reliable. Or we might also decide that we go with different top level domains on the name server domains.

So these are all individual things that we're still looking into more closely.

And the goal is really to have new names of domains that are even more reliable.

And the likelihood that something happens will be reduced significantly.

Awesome.

Okay. Thank you very much. And then last question.

If I if someone listening today wants to know more or wants to be in on any additional updates on our DNS services, where should they look out?

Look out for.

Them?

Obviously on the block. But I think we will actually be very soon publishing developer documentation for DNS specifically.

So that should go out before the end of the year, if not very, very early next year.

And I think that's a really, really good place to get familiar with Cloudflare DNS offering.

Okay.

Thank you very much, Anas. Sure.

So moving on to the last announcement we're trying to cover in the 30 minutes today, one that is much closer to my heart as I've worked personally with Dan on this is our new product, which is called Shield.

But let's let's begin with the basics, right.

Dan, do you mind giving us an overview of what is what's the context?

What does page two do at the very basic level?

Yeah, absolutely.

So very exciting general availability today of page shield with actually some functionality for all paying customers, really cool stuff.

And ultimately people ask, you know, why do we need it?

Well, Page helps us see, understand and really mitigate the risk present in third party dependencies or third party JavaScript dependencies.

And it turns out.

Michael Wink, wink.

You know, Michael and I have worked really closely on this when this dependency risk goes unchecked and there was a very unfortunate outcome.

And that of course, is an attack through or via a compromised dependency that targets Web visitors or people going to say one of our customers websites.

And of course, these attacks can steal any sensitive data that, say, a Web visitor enters into their browser or it can also say, be used for cryptomining or delivering malware.

So there can be a very, very important, unfortunate attack that occurs when this third party risk goes unchecked.

And, you know, I feel like, Michael, we've commonly in application security work thought about saying server side but this is this is client side isn't it.

Right.

Yeah. So... So let me make sure I fully understand the way we're describing it here.

So we moved over from DNS, which is how people access websites, right?

You type a domain and then the domain gets resolved to an IP and you connect to a website.

And here we're saying that for websites that are behind Cloudflare, we can now essentially make the end user browser experience.

So now what's happening on the server for that?

We have things like the Web application firewall.

We can make the browser experience safer and make sure that any hacker trying to infiltrate the browser directly is going to have a very hard time.

Is that a good way?

A good way to think about it? Absolutely.

Absolutely. We commonly think about it protecting our customer servers.

Well, this is making sure that the websites that their visitors interact with are as safe as possible.

Got it.

And then you mentioned dependencies quite a few times. What is for our audience again?

What is the dependency in the context of web applications and why are people using dependencies in websites?

Good question.

This is really probably the most important sort of level setting question.

And a dependency really is, at its simplest, is a piece of third party code that say your site or your application needs to function.

Now this can be sort of under the hood stuff like checking user agents, or it can be something that's more sort of conspicuous that everybody sees an interaction with, like a chat bot or shopping cart functionality.

Right.

And to be clear here, so this is this code is third party. It doesn't belong to the application or the site or it actually it's sort of borrowed from somebody else.

So this code is not under the sort of application owner's control.

So that, of course, is where we can start to see that this risk.

Now the glass.

Let's look at the glass half full.

Why?

Why do we use dependencies? And this the really useful the reason why like the upside here is that they can save a lot of time, hours and hours, hundreds of thousands of hours in terms of developing coding things, because you don't have to necessarily sort of reinvent functionality that already exists in a third party dependency that you can just sort of borrow and integrate right into your site.

And that being the case, it's it's such an easy way to add functionality that we see them all over the place.

Right.

And so I think most people are familiar with Cloudflare and sites will probably know this.

But I think it's important to remind folks that given that it's such an easy way to add functionality to website, we see dependencies all over the place.

And you know, there are some stats like Web Almanac that tracks this stuff.

And Michael, this won't surprise you because you've been sort of a product lead here.

But, you know, for medium sized sites, there's at least dozens. Now, when you get into sort of the larger sites, we're looking at north of 90 dependencies and if not in due to north of 100.

Right.

And we think about that. That's like 100 different ways into a website and that's a lot of risk.

And that, of course, brings it back to, you know, why we bother with Page Shields.

Right?

Right. Yeah. And especially the other the other thought I had there nowadays, you know, anyone starting a new business or a new technology idea, chances are they're going to build a SaaS based business, right?

So it's becoming easier and easier for you to embed these plugins or applications into your site and they just get loaded by the SAS provider, right?

You're not sort of downloading the code, even if that's still the third party dependencies today.

Adding those in has become really, really, really, really easy.

So, you know, diving a little deeper here, let's say I'm building a website and I've added all sorts of third party dependencies, chat systems, analytic systems, date pickers, all sorts of different things.

How does an attacker actually leverage the fact that I'm using third party dependencies to infiltrate my end user data or my site?

Yeah, indeed.

And, you know, congratulations. You've saved a lot of time by using these dependencies.

For starters, right now it turns out the attackers this is not lost on attackers.

Right.

That organizations, of course, we rely on these. And you go to GitHub, you see hundreds of thousands of options for many of these different functionalities you want to plug in your site.

Attackers realize this and that's where they're starting.

They realize many of these dependencies are built by well-meaning individuals, developers, where security may not be top of mind.

Right.

Not everybody is a Google. Right.

There's obviously a lot of dependencies from Google where they've got all the users in the world to worry about security.

Well, that's not always the case.

And that is why an attacker will start with a dependency, because, again, that's the easiest way.

And sort of the back door, the side door into an organization through the website.

And so, of course, they'll target these dependencies they see running on your site.

And again, it might be the shopping cart, right, to process payments. And of course, once they're able to execute infected code, at that point, it's bad news.

And you may well not even be aware that it's that the attack is running for.

We've seen this in the real world from a few hours to a few months, actually.

Right there is in one case, there was a chat bot, unfortunately, that was compromised on a on a very well known e-commerce site.

The compromised chat bot code was in place for four months.

Four months.

Right.

And so yeah, that's that's real risk. And we've seen airlines compromised, unfortunately, right, where their checkout pages had malicious scripts running for weeks.

Right.

There's there's a real risk here that thanks to or no thanks to attackers. Cool.

So very quickly, before we jump into what are we doing about this problem? How have people try to solve it today?

What is the current approach?

Yeah, indeed.

You know, by and large, we sort of have as an industry relied on something called CSPs or content security policies over the past decade or so in browsers.

And CSPs are headers that effectively browsers use to restrict what can load.

This can be JavaScript or CSS or images or plug ins, really anything that gets loaded into a browser.

Now, CSP is tend to be created manually by security teams using directives and they expressly allow what can load.

And for instance, a CSP might allow this the CDN as the only origin from which scripts can load or prohibit plug in something like that.

But by and.

George Michael CSPs have been been a common way to try to get ahead of these attacks.

And as you know, Dan, you know, the problem with CSPs, of course, is that just specifying an allowance doesn't tell you anything about how malicious the code is, right?

Indeed.

Indeed. You know, a couple of things. So first of all, these CSPs, you have to build a manually that is no small feat.

And what's more is in big sites, new scripts are being added all the time.

So the script monitoring process, it's manual is a real headache.

Right.

And of course, if you get this wrong, right, you don't allow those. Right, right.

resources. Of course, you accidentally break the website.

That's obviously bad.

So what happens? Well, there will be cases where CSPs are deliberately crafted in an overly broad way in order to not accidentally break anything but of course, watered down the security benefits.

They're right. And what's more is, as you said, what if we allow this everything properly and then something turns back, there's something malicious?

Well, CSPs are static lists and there's no actual detections here.

So that's another big shortcoming.

Got it.

And that's why we decided to build and launch page shield today. Right.

So in a in a couple of sentences, how are we approaching the problem and how are we solving the third party dependency?

Absolutely.

So what you customers have to look forward to it. And I sort of look at this in three key areas and please chime in here.

We've got the visibility portion detection and blocking.

And of course, we start with visibility and that's something that all paying customers will get access to starting right now, we'll give them a list of all their JavaScript dependencies.

Right, running at any given point in time.

In addition to that, we'll actually add some alerting.

So if there are new dependencies appearing, there are new host serving dependencies, don't know about it right away.

And what's more, we'll tell them exactly where it is in their site, in their application with page attribution.

Now, the detection piece, as you mentioned, I want to kick over to you.

So of course, we start the visibility complemented with detection, right?

Well, how does that work?

Right.

So what we're doing here actually is not relying on CSPs, but rather we're going to scan and download all those third party dependencies on our side and then make a bunch of different checks on them, such as checking against threat intel feeds we have access to make sure that JavaScript is not being hosted or loaded by compromised applications.

But even more interestingly, we built a classifier that will actually look at all the JavaScript files that are doing data exfiltration to new endpoints and will highlight them in the dashboard to make sure that you get to review them and potentially block them.

Of course, if they are showing malicious behavior, that's not intended.

And the last part you mentioned, then, of course, the blocking.

We're going to get to that very soon, early next year.

But in terms of turning on page shield, it is now available to all paid plans all the way from pro to biz and enterprise.

So head over to the cloud for Dashboard.

It is a single click and then you get going with page field.

And with that we've got about 10 seconds left.

So I'm going to say thank you to Abe Annice and Dan for joining me today and for everyone else.

Keep an eye on our blog for all new CIO Week announcements. Thank you very much.

Thumbnail image for video "CIO Week"

CIO Week
Relive the exciting announcements from CIO Week! Check out the CIO Week Hub to find all of our announcements and blog posts!
Watch more episodes