🎂 RBAC for Every Plan

Hello, everybody. My name is Garrett. I'm a director of product here at Cloudflare. And thank you for joining us for this Cloudflare TV session to celebrate Claire's 12th birthday year. Today, we're going to be talking about a very exciting announcement, our back for all. Or if you're not familiar with the term our roll based access control. Today I'm joined by Joseph. Joseph, why don't you introduce yourself and tell us a little bit more about what is our role? What have we actually announced today for all of our customers for Birthday Week? Hi, I'm Joseph, so I'm a product manager at Cloudflare and our back for all is making role based access or the ability to assign roles available for all accounts across every plan. What we're what we really wanted to do here is enhance security for everyone. And where these roles have been available primarily for enterprise customers for a while, they are now being released to our free and PAYGO customers. That is awesome. Obviously Clever wants to make the internet better. We want to make sure that all of our customers and the Internet is more secure. Part of that is ensuring that if you're using Cloudflare, Cloudflare itself is more secure for you, and so giving you more control over who has access to what in your account obviously helps us to achieve that goal. Joseph, for those that might be a bit unfamiliar with identity access management, rule based access control, can you kind of sort of start us at the most basic level, like what, identity access management? It's kind of a big term, sort of what does that mean? What is the core components of that? Yep. Identity access management is really a mixture of a few things. It is trying to identify who you are and being able to actually prove it and then being able to actually do something. The first part ID is generally done via something like a email or a username. It is your specific identity and what a web property knows you have. In one case, it could be like showing your ID in real life. The next portion of that is authentication. Being able to on top of being on top of knowing who you are, being able to prove it. How we can generally do this is via a password, a biometric, a yubikey second factor authentication, something that really proves that on top of you claiming who you are, you can prove it. And then that last part is authorization, a policy that can ensure that you can do what you're trying to do. Policy is ensure the right users have the right access to the right resources. And a good example of this in real life is you can show up to a site you may not be qualified or allowed to do an action. You may want to avoid a random person rolling a token on a specific website. And what roles do in this case if they although they allow someone with the appropriate access into the account, they restrict certain actions from being taken by that person. Got it. So an example, another example might be like, I want you to log in and see my account because you're maybe helping me manage something, but I don't want you to touch my DNS records because those are very sensitive. If you mess with them, make a mistake, right? It could take down my website. So I want to give you access and maybe edit to something else in my account, but don't touch my DNS records. They're super sensitive and I can basically guarantee that through the sort of rules that I grant you in my account. Is that correct? That is correct. Got it. Okay. So I'm let's say I'm someone using Cloudflare or some other service, Right. How do I think about. What kind of grants? I have a team of people, maybe five or six people that I work with that I want to give access to Cloudflare or whatever service it is. How do I think about how do I do this smartly so that I don't minimize the risk of mistakes or hacks or malicious actors having any effect on my on affecting my services. So the first thing to think about is the concept of least privilege. Least privilege is the idea that you only grant the appropriate access for the particular job. We this minimizes the attack surface. If someone were to gain access to a particular account, even if that credential was stolen, you may be able to limit their actions in how we do this. If you have five or six people on your team, let's first try to identify what exactly each person is going to do. You may have, for example, on that five or six person team, one person who really is going to allow pushing of code to prod and everyone else could be working solely on ensuring that the code is up to snuff and needs that final approval. If you do that, you may want to enable that first user with more privileges than the other ones, the bottom three or four either, if they may be granted a read only rule so that they can look at the configuration and understand how to build around that. Whereas when. That one user that is allowed to push to production, they may have the ability to edit and with the suggestions of all the other users, they would go in and do that. When you are after you divide up that access, divide up the team into the appropriate things they need to do. We currently have a wide number of roles that apply both to everything across an account and to specific products. So you'll try to figure out which products specifically need access to. If somebody doesn't need access to, say, Zero Trust, you would avoid granting them access to that. And a word of warning. Be careful about assigning too much Super admin and the billing role. Have access to billing. You may want to keep that even from the person who is trying to deploy. That may be solely at the owner of the account level and then everyone else would have various levels of administration permissions. Got it. So obviously provides you a bunch of different types of roles, all of them segmented per product. So if I'm in my account, I'm using both Zero Trust zones products and maybe things like Cloudflare Images or even some of the Workers ecosystem. I can grant only access to the specific products to the people that need them. So if one person is managing Zero Trust, they get that access, one person is managing Cloudflare Images they get that access, right? But there's no cross-pollination. Someone with Images control can't accidentally mess up my access policy, which might mess up my team's ability to use our services. That is correct. The further segregated individual users are with their access, the less chance you have of either something malicious happening or someone accidentally stepping on someone else's toes. Got it. And I assume this access extends through both our dashboard experience and our API experience. So no matter how you're accessing Cloudflare, whether it's the UI or through the API, right, you kind of have these guarantees so that you don't have to worry about someone stepping out of bounds just because they're using our API or one of our libraries like Wrangler or TerraForm. That is correct. Our API controls are the exact same as our dashboard controls. Anything that you have assigned as a role in Dashboard, we validate every API request to the same level of permissions. Got it. Okay, cool. Why don't. Can you show us how this works? It'll be great to see. For those that aren't familiar with some of our controls. What does it do? How do I. How do I use this? I want to grant granular access. How do I actually do that? Yeah. In this case, I'm sharing my screen and this is a demo account that I currently have within here. You'll see that this is the Cloudflare dashboard and all of the products on the left side within Manage account, we are now able to click where previously there was an invite bar here and the options for admin and super admin we are now able to click invite. And really figure out the scope and the roles that we want to assign. In this case, I will try to invite test either at as dot com. Add that to the list. And what we can do from here is if we include all domains within an account, we have a wide range of roles here from super admin, which we previously only allowed one super admin per account to specific Cloudflare product items like Cloudflare product roles like Cloudflare Images, Sarah's Trust and Safety and the Magic Network down to analytics, billing and administrator. Got it. So previously we only had, if I remember correctly, for self-serve customers, we had super admin, which was the initial owner and it can only be one. And then everyone else had to be an administrator. So now basically when you invite someone, you can choose any number of these roles and even now you can have other super administrators in your account. So you don't have to have just one anymore, which is really great in case something happens and one person gets locked out or leaves a company, right? You now have two owners of the account that can keep managing it. Yep. In addition to these roles, we are in the process of rolling out specific domain groups and domain roles. So these will apply to a specific domain as opposed to the whole account. And if you have a grouping of domains, you will be able to make a domain group. Such that you can manage the team of users that have access solely to solely to those domains. What's an example of why I might want to create a domain group as opposed to just assigning permissions to individual domains? So in this case, if you had, say, a group of developers on your team that had both a staging and a production domain, you may want to limit access to the production domain, but grant access solely to the staging domain to most of your developers. I see. So I can basically say you get access to control, staging, do whatever you want or whatever I want to allow you to, but I don't want to give you access to production because I only want myself as the account owner or me and you, for example, like the two most trusted people to better make changes to the production domain or domains. And that's correct. And if this expands over several sites, being able to group them such that you have all of the staging domains in a single group and all of the production domains in a single domain group may make it easier for administration. Got it. And then if I if I add another domain to my account, if that's staging domain, then as long as I add it to the domain group, then everyone that had staging domain access gets access to that domain as well. I don't have to go and update every single individual users permissions in the system, which could be what? Or could be ten or 20? Yeah, let's say you had 20 users. That should save you quite a bit of work. Instead of having to go into each individual of those 20 users and add a additional domain, you should be able to just add it to the domain group and it will show up for them. Got it. Very, very interesting. And then, you know this some folks might have read the blog post last week or saw our TV segment as well. But this idea of scoping to specific domains or domain groups, this is a very new capability, is it not? This is a very new capability. This has just gone into general availability last week with our enterprise customers. And we are proud to roll this out for all. We will be looking at additional controls and additional granularity in both of our user sets, both of both for our enterprise customers as well as our self serve customers so we can continue increasing granularity and making it easier to really restrict access down to your down to the Fed you need on your team. Got it. Yeah. I think from enterprise to available to all in a week might be a record for how quickly we've made something available that was initially restricted to everyone. So that's exciting to see that this being such an important part of keeping our account secure, something about where we're able to give to everyone so they can do exactly what they need. I'm curious, can you sort of show we sort of looking at this scope section and we have operators and types, can you sort of talk about a little bit of what is what does it include? Why do I need to include or I assume maybe there's an exclude option, like what? What does that really do for me? Yeah. If you. Had. We are now able to operate on multiple. Multiple domains at the same time, if we wanted to say include a person in all of the set of production domains except for a particular production domain, we have the exclude operator and we would be able to then grant someone access to. Specifically that all of the production domains except one. We can also have all, let's say, all of the staging domains and also include a specific production domain. We're hoping that by assigning basically three parts to every invite the invitee or the actor, a scope that will allow us to restrict or deny, include or exclude specific resources and a specific role, we'll be able to grow out the system to really cover any subset of situation where we have specific resources. Got it. So really here, if I kind of think about this on a more theoretical level, the first question is who? Who am I giving access to? Right. Pretty clear. Those are users that I invite to my account. The scope here is sort of what are the set of resources in this case? What are the set of domains or accounts? Obviously, we're in a single account, but I can additionally say what are the specific domains I want to grant access to? And I can define that list as a list of domains. I can exclude domains. I can include groups of domains. Right. So I have a lot of flexibility to what's the easiest way to manage the if I have 50 domains in my account, I don't obviously want to be writing all 50 down every time I can group them exclude include as necessary. And then last we have sort of the role which is really the set of permissions that I'm granting to that person for those sets of resources, whatever they may be. And so it sounds like obviously this is a pretty we can obviously this could be generalized. We're talking about domains here. But I assume that theoretically this could not just be tied to domains. Is that correct? That is correct. We are currently looking into what other resources we could apply this to. Everything on Cloudflare to some degree is under a hierarchy, generally under the account. And within that there are items such as Workers, Routes, individual DNS records. We're really hoping that by crafting our insights to not solely be who are you, which count and what role you get. We expand the level of customization by going you have by making a specific subset of scopes so we can really restrict down to, say, an individual record in the future. Got it. So there's potentially a future conversation that we'd be having like this, except instead of talking about domains, we'd be talking about something like DNS records and talking about how, oh, you can specify the records or some other aspect of them that you want to grant this user to, but not grant to others. Is that correct? That is correct. And we're really looking forward to it. Yeah, that sounds like it'd be super powerful, right? Because more and more obviously, domains have been a very core part of Cloudflare. One of the first things kind of the initial thing that we have, but we have a lot of different products now. So knowing that sort of under the covers, this supports more than just domains means that we can build out those additional capabilities and give if you're if you're a developer and you're building all your applications specifically on Workers, you might have multiple people in your account, you might have multiple different applications that you're building knowing that you've got a grant, sort of this level of granular access to those different applications, right, is really exciting and really powerful. Yep. And yeah, in addition to all of these authorization changes we're hoping to make in the future, we are looking to really build out our authentication stack as well. What do you mean by that in. Terms of our authentication stack? You'll notice that earlier this year we have put out our first social login and we have been doing some work with regards to enhancing our to offer experience. What we really want to do in the future is ensure that we're reducing the proliferation of passwords where there is a social login that we can allow users to use. We may. We want to enhance that. So there is one less password for you to remember as well as one less password for you to forget. Yes, it's definitely even I find it difficult to try and keep track of everything. So yeah, I believe the log in we added was with Apple. Correct. And so you're basically saying that we could extend that into other avenues. And then you mentioned. You mentioned to. Can you talk a little bit more about sort of what we have there, what we've done maybe recently that's bolstered things there? Yeah. With regards to our two, we have really bolstered some of our recovery capabilities in terms of we know that people can forget their two IFA, whether that means they're moving to a new phone, they may have forgotten their original email address, email password. If you have a backup recovery key on your account, you'll be able to use one of those to regain access to your account and really reset your to IFA such that it can allow you to use the account again. That reduces the amount of. External help that you really need to get back into that account. We also have now a automated reset that takes a little bit longer than the backup recovery code, but in some cases can be automatic. It gives us a safety buffer of three days prior to giving you access to the account. But what we're able to do there is really reset your 2FA. Got it. So if I understand it correctly, if I'm trying to manage my Cloudflare account, I can make sure that I don't lose access. Obviously, no one else gets access to my account to cafes. Sort of the gold standard for securing access. We support multiple two of the methods. So don't just have if you're using Google Authenticator or you might have a hardware key, for example, don't just have one, have multiple. If you lose one, you have another that you can depend on. I believe, as you mentioned, we have we do have recovery keys, which when you set up to three for first time, we provide to you. You know, we try and have you download those, make sure you download those, make sure you store them somewhere that's secure, but that you can access if you need to. And then if all of those options don't work out for one reason or another, people use them, then we have this sort of automated system that folks can use. Is that an accurate summation of what exists today? That is a very accurate summation. We are looking at all times to figure out how we can enhance them. This could be additional to factors in the future. Yeah, sometimes if we can remove that even outside the too far removed the first factor, the password, it may make it easier. Got it. Got it. Yeah. And I know that with with 2FA, we support all sorts of the modern methods. So if you're on iOS, you have sort of either touch ID or face ID that you can use to log into your Cloudflare account if you're on an Android device. Google has sort of the equivalents, so you don't have to worry about authentication apps anymore. And then obviously really the true most secure form is a hardware key, a physical key. For folks that aren't familiar, we just actually announced a partnership with Yubico where if you are Cloudflare customer, you sign into your account, you'll see an offer presented that you can go to Yubico and buy. I think it's up to ten keys at basically the best discount you'll find. And so you can use that if you want to properly, really properly secure your Cloudflare account and any other important accounts you have on the internet. Hardware keys are the way to do it. It's what we use at Cloudflare. It's the reason why entities that have tried to phish employees or whatnot to try and gain access to our systems have failed because we have the requirement that logins must go through a hard key. I have a little one sitting in my laptop. I assume you do as well, just as does pretty much everyone in Cloudflare. And so that gives a lot of peace of mind to help secure our entire company and keep us protected. And so even if you're not a company the size of Cloudflare, you want to stay safe. You don't want any part of your infrastructure attacked or taken over. You don't want your Cloudflare account taken over given what it protects. And so hardware keys are absolutely the way to go there that assign aside. So this is all really cool love to see that all this power is now in all of our customers hands. If I'm a customer, do I have this? When do I get this? How do I get this? What's the next step there? So the next steps, going back to our overall, we will be doing a progressive rollout. We want to ensure that the scale of this works adequately and this progressive rollout. All self serve customers should be enrolled on this automatically. Generally, within the next month you'll be able to notice generally by going to your members page and seeing that you no longer have just an invite bar there and you'll have an invite button instead. Got it. So effectively by Halloween, that's the end of October for those that celebrate it, all of our customers should have this and we'll better use all these features. Awesome. That is super excited. Super excited here. This has been a long standing request from a lot of our customers and definitely glad to see that we're able to provide this kind of benefit for customers. Kind of looking forward. I know we talked about kind of some things that we're planning to do, but what's some other stuff that might be on the horizon that customer should be in the know about? So, yeah, in our in our authentication space, definitely look forward to more social login in our authorization space. We are looking forward to adding more roles with regards to our self-serve customers specifically. We are entertaining the eye. How you can try to find us with suggestions for roles would be generally through the community. We do regularly check that. If you think. Where we have. Roles already, we may not be adding them, but if there is a specific segment of the Cloudflare product where you feel like there may be use for a new role, please make a post in the community. We generally follow up and we're always watching so we can take those considerations and suggestions in mind. We also have some work. Really more with our enterprise customers around being able to manage our customers more easily. And that may involve some features rolling down to our self-serve customer base as well. Got it. Okay. So if you're using all this new stuff in use, maybe a role that you think should exist for some product or somebody that does this thing, but you can't give them the right permissions by combining roles, then community forums. If you're unfamiliar, community.cloudflare.com is the place to be between PMs and Cloudflare employees and our MVPs who help with the forums. It's a great place to get help and it's also a good place to provide feedback in this way. So if there are things that you like to see that aren't there in the rec system, please do let us know. We're always curious to learn how our users are actually using Cloudflare And when we come up, when we hear about new use cases, it really reframes how we think about expanding our system. Yes. Yes. Customer feedback is a lifeblood of how Cloudflare makes Cloudflare better. So please, please keep it coming. Cool. Anything else that you'd like to share? Anything else worth calling up for? We wrap up for this. I don't think I have too many other surprises in my sleeve. I am looking forward to getting back to work and building out. These are authentication and authorization capabilities and hopefully we'll be back on Cloudflare TV again soon. Yeah, absolutely. I can't have you spoil all the fun, right? We have to keep some surprises in our pocket. But, of course, if you aren't already follow the blog. Any major announcements show up there. And of course, then there may be a follow up class or TV sessions as well. Well, just thanks for talking us through this and showing me and our customers how to take full advantage of our back and secure their accounts properly. Obviously, kudos to you and the team for shipping us. This is a very, very big milestone for our customer security. So thank you for that. And thank you, Garrett, for the opportunity to show our customers our new capabilities. I'm really looking forward to getting this rolled out and hearing all the feedback. Awesome. Well, any time with that. Thank you, everyone, for watching. Hope you enjoy the rest of the announcements coming with Birthday Week. We're not quite done. They're still only Thursday, so there's still more to come. Of course, if you have any questions, feel free to reach out in the community form. We will find it and we will get back to you. Thanks, everyone. Have a good day. Thanks.