🚀 Launch Day @Birthday Week

Hello, everyone. Welcome to this Cloudflare TV session on API Shield. I'm Daniele Molteni and I'm the product manager for Fiber Rules. And with me, there is Patrick Donahue, which is the director of our security products. Hey, Daniele, how's it going? Good. Yeah, very well. This is my first birthday week, so yeah, this is an exciting new experience. I think you've done a lot of this in the past, so you must have an interesting perspective. What does it make so special, like birthday week in general and perhaps this one? Yeah, birthday week is always a fun, a little bit stressful week at Cloudflare. I think the thing that makes it a little stressful is, as you know, in product management, you've got two things that you're talking to your engineering team about. You've got the feature set that you're looking for and then you typically have a date and you kind of ask, OK, if we need to deliver by this date, what can we get? Or if we need all of this, when can you give it to us? And this is a little bit different because we're kind of locked into a very specific week here. And so it's always fun. It adds a little bit of extra pressure. But for me, it kind of feels like a lot of it feels like the earlier days of Cloudflare. When I started a little over five years ago, we were very much kind of driving towards specific dates and we still do this for customers to some extent. But you always want to do that in small doses when you need to and not always be so, so focused on dates. You want to kind of a rolling release of features and products. And I think we've done a great job of that over the years. Also, I would say you get to work with a number of different teams. And so a lot of the stuff that we do on birthday week, we're giving back to the Internet. We are doing stuff across different functions. And so I think in this particular one, we got to work with obviously the firewall team that you're product managing, but also the SSL team, which I used to work with. I hear my headphones die, so I'm going to turn these off. Great. So the other thing that makes it special is the things that we ship really have a big impact ultimately. And so you don't really know at the time that you're shipping something, how important it's going to be to Cloudflare in general. And so everything that we're doing is free for birthday week. It's giving back to the Internet at large. And ultimately, it's exciting to see how customers use these products. And so I remember we did something we called GeoKey Manager one year, which was an ability to tell us where your private key could be decrypted. And so if you had various opinions of different parts of the world, or maybe regulations you had to follow, or you could only do things in the US or the EU, or specific areas of the world that your security team has said to avoid, you could have that control. And so initially, we launched it, and it was just a few things from a dropdown. And then later, we gave very, very more granular controls over time that people took advantage of. And so I think it's always fun, and it's a little bit scary to put something out before it's fully polished and before you know if you're going to use it. But I think at Cloudflare, we pride ourselves on releasing stuff early and often. And you want to listen to the feedback that you get from customers. And so I'm really excited to see the API Shield project that you just shipped. I'm really excited to see how people use it. And then we'll get into some of the capabilities. But my anticipation is that this is a starting point for us, and we're going to get a lot of great feedback from the release, and we're going to listen to that feedback, and prioritize features, and do things that product managers do, and take us to the next step and help build a roadmap out. One other birthday week project that I think is fun to talk about is Universal SSL, which actually has a lot of parallels to this project, as we'll get into. But it used to be really hard for users to get HTTPS capabilities on their side, and getting an SSL certificate. I remember the first one I got, you had to write, physically send mail with a certificate that was stamped by the Secretary of State, at least for me in Massachusetts. And we made that a whole lot easier, birthday week one year, with what we call Universal SSL, which is providing that whole process and managed lifecycle of certificate issuance and renewal. The thing that we didn't ship during birthday week, which I didn't find out until I started product managing that team, was we shipped the ability to issue certificates, but we didn't ship the ability to renew certificates. And so, one of my first responsibilities as product manager for that team was figuring out, how do we actually go now renew all these millions of certificates that we've been issuing for customers? And so, that's kind of what I mean about getting that value into the customer's hands early. And then, that renewal, these were one year search, you didn't need that at day one, but you're able to give that value and make people's lives a lot easier managing their sites. And then, you can kind of prioritize the other parts of it that are needed a bit later. And so, I think that's the approach that we take. And birthday week, for me, helps reinforce that, right? Because we're working on things throughout the quarter and we set our plans, but often a lot of the stuff that we decide to do for birthday week is somewhat late breaking in terms of, maybe it's something that we were planning to do later in the year, but we said, hey, can we pull this up? And it causes, I think, a bit of anxiety, but it's always good when we can ship and shipping makes our lives feel good on the product management side, as you're well aware. So anyway, that's what I like about birthday week. I think just giving back and getting things in people's hands and getting feedback. That sounds great. I think and I think it's been a great experience because I could see the process of developing a product end-to-end in a very short, compressed amount of time. So, I think this is a great learning opportunity for me from, of course, technical point of view, but also from within the company. I mean, it's such a crazy time where we cannot see each other and meet each other, right? So, being able to, being out there and having to meet other people from different teams, as you mentioned, this, I think it was a great way for me to link to the broader organization, get to know more people, understand the processes, and then let's say, yeah, the, all the nuances that it takes to take basically an idea or product to the finish line and give it to customers. So, I think that was fantastic. Yeah. Yeah, absolutely. I think I've been questioning. Yeah. I was just going to say, you got to see the design process, the product design process, which years ago wasn't a team we had, right? So, now we have some experts who help us figure out, okay, what is that user experience like? And how do we make things as simple and easy to use as possible? You got to work with the front-end engineering teams to actually build the user interfaces and test them. You got to work with the backend teams that were building the APIs. And as the APIs got built, we're making curl calls or postman calls or whatever it may be to sort of test that stuff in parallel. And then you got to kind of weave it together at the end. Yeah, absolutely. And I could see what you were talking about, that this balance between giving value to the customer, but at the same time, making it manageable to be shipped in a short amount of time. So, definitely a great learning opportunity. So, let's talk about what we actually shipped. So, let's get into that. So, tell me about what we released this morning and kind of why did we release that? Why did we decide on that? Yeah. So, we are releasing the API Shield. So, that's a product which is specifically designed to protect API traffic of our customers and users in general, actually. The reason why is because API in general becoming more and more prominent in the Internet and connected world. So, most of mobile apps, IoT devices communicate via APIs. And we even looked at our data, right? So, across the 18 million requests we see per second through the Cloudflare network, more than 50% are directed towards APIs. So, it's a huge part of the traffic and it's actually growing as well quite fast. So, we decided basically to target directly this space and develop a product which is as the goal of streamlining the development and deployment of security products. Yeah, that's terrific. I mean, I think the thing that I've long thought is we've done a number of things that are really great features and security capabilities to protect APIs historically. And so, how is this different what we're releasing today versus all the stuff that we've been doing historically given I think it's about half of the traffic that's coming through our network, as you mentioned, is API traffic. What is different about what we release today? Yeah, I think most of our products are really being used for API, right? And protect APIs. If you take firewalls, the WAF, rate limiting, I mean, these are tools that on a daily basis, they're just used for API traffic. The thing that is different now is that we are basically designing a product specifically for API traffic. And the way you deploy it and the way you basically the experience from a customer perspective, from user perspective to interact with that product is different. So, it's made to streamline the process of getting access to the product and deploying it on your basically Internet assets. Got it. That makes a lot of sense. And so, what specific, if you think about the capabilities that we develop that are very targeted towards, as you mentioned, that streamlined API security experience, what specific capabilities do we introduce to help solve some of those problems? Yeah. So, with API Shield, I mean, one of the core functionalities is a strong authentication. So, we basically developed API Shield with mobile apps and IoT in mind. So, the first thing we wanted to start was basically starting with providing encryption authentication by a mutual TLS. This is the very basics and we talk, all right, okay, let's build a product based on this. And then on top of that, we can add extra functionality. So, we have added, we're adding schema validation, for example, and GeoPC support, which is another birthday week product that has been announced at the same time. But of course, on top of that, we are going to give the out-of-the-box DDoS protection, the WAF as well, that will come as part of the Cloudflare standard offering, basically. And the idea is that over time, we plan to add more capabilities and the API Shield will be the place where you can deploy seemingly all features that are API related. Perfect. And I know we'll get into the interface in a little bit, but I think the thing that I really like about this and things that we're working towards are the fact that these ultimately will run as part of the same firewall rules engine. And so, I think as we, you and I talk about this a lot, but we've built this really powerful Rust-based engine where it's very expressive. Customers can write rules to match traffic and take action on traffic. And they can do that by interpolating all different things about the request and increasingly for intelligence and all sorts of other attributes. We're adding capabilities to that toolbox today. And I think the thing that I really like about that is everything that we've shipped, we can combine with all of our other security products. And so, if you want to write a API Shield rule that does strong authentication with client certificates and does schema validation, you can also combine that with a bot score or soon different IP intelligence information that we're getting ready to release. And so, that's what really is exciting for me as also a user of Cloudflare before I was a customer. So, that gets me excited about that too. So, why don't we drive in, dive in rather a little bit into the capabilities. Do you want to start with the mutual TLS side? Yeah. I mean, I know you have been product managing the SSL team in the past. So, you're the best person to- Sure, sure. Yeah, I'll start with that one and then we can kind of go from there to the other capabilities. And so, I think the thing that if you're somebody that's putting an API up on the Internet, as I've done in previous employment, I would put that API up and I would expect my customers to connect to that. And I also expect some not exactly customers trying to connect to that and trying to poke and prod and maybe exfiltrate data and see what they can do. Or maybe it's a pre-API to use, but you want to know exactly who those users are. And so, one of the ways that you can do that is you can just hand out credentials. So, you can let people specify a username and password, or you can do some sort of token issuance. The challenge with the user and passwords, and by the way, a lot of these APIs are powering our dashboard. And so, a lot of APIs are powering user experiences. And so, they may be using username and passwords. And I think as we've all seen, people tend to reuse those. And as much as I know that we're in security month now, we're doing ongoing training with CloudFarm employees. But regardless, people tend to reuse those and sites can get compromised, especially people that are leaking them in plain text. And I think the thing about client certificates is that these are uniquely issued and not really used. Because in order to reuse it, you would need to use the certificate authority that is signing it on the server side. And so, it's not something that would be easily replicated. And so, I think that the thing that I like about this is we can provide that strong identity by issuing certificates. And we can do it in a way that, historically, it's very hard to do this yourself, because you either need to, hard or expensive, right? You need to try to bootstrap something with, whether it's OpenSSL or Cloudflare's CFSSL, which Let's Encrypt and others are using, to power Boulder and their CA. If you're trying to spin that yourself, it can be very difficult. And figuring out where you're managing your CA and your signing authorities and your private keys behind those, that can be very cumbersome. And so, what we did with API Shield is we actually released a fully managed client certificate offering. And so, customers can actually go within the SSL TLS tab in the dashboard, and they can actually go in there now and say, okay, I want to issue a client certificate. And I want to do that with a certificate authority that is fully managed by Cloudflare. What that means is we take care of initializing certificate authority, storing the private key securely, signing the certificate signing requests, and everything involved in that. And so, the initial launch is we fully manage that. We understand customers will want to provide their own, and you can do that today with Cloudflare access. Maybe this is something that gets brought into API Shield. We'll kind of see what the feedback looks like. But the idea there is that that process now becomes just a click of a few buttons, where it used to be a very difficult and onerous and potentially risky process to do yourself. And so, every zone in Cloudflare now has access to this for free. You can issue client certificates, and we'll get into how those are enforced and firewall rules. But the point is, it's fully managed, and that's really what saves the time and simplifies. Yeah, sounds great. So, let's take a look at another feature. So, I guess the next one we are also releasing or about to release is schema validation, which is a feature which at the moment is in closed beta, but we are planning to release it soon to make it generally available. So, the idea behind the schema validation is that, of course, I mean, you have strong authentication, which is the first layer of security you can place, but you can still perhaps, yeah, you can get a certificate somehow and start to forge requests that are like, might be malicious. So, another way to add the next layer of security could be to basically check whether the API call complies with a schema. The schema is nothing else than kind of a skeleton, or let's say, yeah, the schema of how you expect your API calls to be, to what kind of parameters you're expecting, where, and what's the structure. And what you can do with this feature is basically you upload your schema, and the firewall automatically basically builds a positive security model based on that schema. So, you're going to look at the, for example, API endpoints, and for every endpoint, you might have certain rules that enforce their present parameters, perhaps query parameters, the method you're calling is the correct one, and you're basically, what you're actually doing is eliminating the noise. It's in a way. I was just, that elimination of noise, I was just thinking that to myself, like that is something I meant to mention on the certificate side, but if you're only accepting API requests from somebody that you've handed a client certificate to, you've eliminated a lot of that drive -by noise in the Internet, right? Somebody trying to scan your site, and I think where you were headed as well on the schema validation side is if you're also then eliminating the noise of improperly designed requests, and often requests that are, you know, an attempt to exploit what is running actually behind the scenes on the API. And so, if that input isn't parsed correctly or handled correctly, that solves a lot of that noise, as you mentioned. Yeah, so that's, yeah, definitely something we're looking forward to make it available for all our customers, but yeah, at the moment, it's in closed beta, so if you're interested, yeah, do reach out. We are gonna keep you posted on the development of that. One of the things you said was positive security model, and we didn't really get into that early on. What do you mean by a positive security model? A positive security model is like, is the, in a way, is the opposite of what we do today, right? So, for example, you want to block, when you define a firewall, you block traffic that comes from a certain country, or perhaps from a certain IP range, or you basically define a rule that its aim is to block traffic from, that can be, that you believe can be malicious. The positive security model is the opposite. You say what you expect in terms of traffic be good traffic, and whatever doesn't fit with that model, with the model, you basically, you block, you filter it out. So, that's what we mean, and that's why schema validation falls into this paradigm, because it's more like, I tell you what I'm gonna expect, and where, and what else, whatever doesn't comply with that, yeah, I'm gonna drop it. Yeah, that makes a lot of sense, and I actually hear that a lot from customers. I was on a call a couple weeks ago, and the customer said to me, I want to put my security posture at the edge, and I only want to see stuff that shows up on my infrastructure that you have told me is good, based on, or you validated as good, based on what I've told you is acceptable, and they said, this customer runs a kind of multi-cloud setup, and so they wanted to enforce that in one place, and then only on, I think it was Azure, and maybe AWS, or DCPA, can't remember the other one, in both of those cases, they said, I only want to see traffic that is past the requirements that I have imposed on it. So, one other thing you mentioned was gRPC support, and so I know that we had a separate blog post today by the protocols team, that's super exciting to hear, can you tell me a little bit about why gRPC is relevant to API Shield and APIs in general? Yeah, gRPC is a protocol that has been around for a while, but it's growing in popularity a lot, and the main reason is because it's a compact and efficient protocol, it's basically a binary protocol, so instead of with JSON, for example, you have long strings to basically transmit data, while with gRPC, what you do, you make it a compact call, so it's really efficient for that reason, but of course, it's not easy to parse with what we have right now with infrastructure right now, so the big challenge for us was to basically introduce in Cloudflare network a way to handle gRPC API calls, so we changed early stages of the request processing pipeline at Cloudflare, so now we can identify gRPC traffic early on, and you can handle it appropriately, appropriately, and this means that even the WAF can run on gRPC, for example, you can inspect all components of the initial gRPC connection request, but also you can basically plug it in into the API Shield, so you can effectively use the API Shield with gRPC traffic. That's great, I mean, I'm hearing from a lot of customers, I was talking to one the other day that said, I think it was by January, they want to have 80% of their traffic moved over from JSON to gRPC binary calls using protobufs, and that's a goal they had set, and so I kind of hinted at that that was something we were working on, and so it's really exciting to see that come into play. I think that's one other thing that I love about birthday week and just shipping products now at Cloudflare in general, is we can ship something on one team and ship something on another team, and those things can kind of be easily plugged in together, and so we were able to take advantage in this case for our API Shield offerings of the protocols team doing all the heavy lifting on the gRPC traffic, and I know we have some ideas in the future about potentially letting people upload their schemas around protobufs and enforcing that as well. If that's something that everybody's listening and that's of interest to you, we'd love to have some beta testers on that and get some thought on my screen. So, this is my first demo, of course, on Cloudflare TV, so no pressure. Okay, so let's take a look here at the UI. So, there are two components to the API Shield. Of course, you have the firewall, as we mentioned, that you built the actual shield, but also you have the MTLS SSL protocol you have to enable. So, these are in two different places. So, you go first on the SSL TLS tab and client certificates. Here, you need basically to get to this point to enable MTLS in the zone you have selected, and within the zone, you have to basically, you're enabling MTLS by deciding which hostname you want to have it on. So, in this case, you get the card from client certificates, then you click on edit, and here you can define the hostname you want. Sure, and while you're typing that, I'll explain to folks listening why that's relevant. So, if you think about a TLS handshake, you need to complete that encryption establishment, session establishment, before you actually can see the underlying web request. And at our edge, when an API is connected and a browser is connected, we need to know the prompt for that client certificate. And so, if you look at the TLS RFCs and you look through what the handshake looks like, usually there's a certificate sent back by the server for server auth. In this case, it also says, okay, now you send me your certificate, which is a client certificate request. And so, you only want to turn that on for just the hostname that you need it for, because you don't want to browse and see it elsewhere. Yeah, thanks for that. Okay, so now we have basically defined the host for the API, and here you see two buttons. One is, of course, create certificate, and the other one, the create a shield. And we're going to first create a certificate in here. So, what do we include here? So, basically, we provide fully managed certificate authority that is unique per zone. So, in each zone, we've got a CA that is used to sign certs. So, in here, you can choose either that we generate the private key, so we can handle the entire process Cloudflare, or you can even specify your key if you want in the CSR. Let's leave it like that for now. And then, of course, you cannot change the certificate authority, but you can choose the validity. In this case, it's between one and 15 years, but yeah, we can create it this way. So, then you land on this page where you see this both certificate and private key. From here, you can simply copy paste the certificate and key on a file and then embed it on your IoT device or mobile app, and then basically build the authentication from there. So, it's really straightforward. Couple things to add. I know that we're working on being able to download this as a PKCS12 format or PFX format, which is a kind of a bundling of those together, and it's something that if you're putting in an IoT device, sorry, iOS, you know, iPhone device, for example, that's the format you would use. And then, I know on the validity period, we've been talking to customers the last couple of weeks that want to do really short-lived ones. And so, I think from a UI perspective, we've got some longer-lived defaults in there. If you're shipping a hardware device, you might put something much, much longer on there, but we also have customers that want to issue these much more frequently. So, these are the types of things that we want to hear from our customer base. So, definitely let us know if there are things you'd like to see. Yeah. So, once you basically create a certificate, you click OK, and you get the certificate added to your list. From here, you can create the API shield rule directly here, or you will also be able to do it from the firewall tab. This is basically a shortcut that directly helps you to streamline or to simplify the creation of the rule. That's what basically we mentioned. Here, of course, you can assign your name for the rule. You get the host name automatically populated. You also get to see how many certificates you have, and that's it. That's all you need. So, once you basically have just added the name, you deploy it, and you get – you're going to see the rule being shown in the firewall. And that's it, and this is basically all you need. Let me make a couple of calls and see how this works. So, let me first turn it off and see. Oh, we're running out of time, so I think we need to be fast. So, there's more information. Sorry? So, this is just a call that goes through and sends a timestamp and a temperature measurement and goes through because it doesn't carry a certificate, and the app shield is off. But when you turn it on, then a certificate is required. So, once you make this call, then you get a 43, so it gets blocked. So, once you add the certificate, though, this post will go through, and you see, like, 201. So, effectively, the shield has blocked the request without valid certificate while allowing when the certificate was embedded. Looks great. We've got five seconds left. So, who is this available for? Who can use this today? Everyone. So, it's free and generally available to all Cloudflare users. Great. All right, we're off. Terrific. Make the most of it. Take care.