🚚 Domain Scoped Roles - GA Week

Hello everybody. Welcome to Cloudflare TV and welcome to GA Week or General Availability Week if you don't know.

My name is Garrett Galow. I'm a Director of Product here at Cloudflare and today I'm joined by Joseph So who's going to walk us through one of our GA announcements, Domain Scope Rules.

Joseph, why don't you introduce yourself and tell us what are we going to be talking about today?

Hi, I'm Joseph So, Product Manager at Cloudflare and today we're going to be talking about Domain Scope Rules, which is a set of access controls that will make it easier for teams to be able to control what their individual team members have access to within a Cloudflare account.

All right, so talking about access controls, permissioning, let's kind of start at the top for those that aren't that familiar either with Cloudflare or even access controls in general.

What is Identity and Access Management?

What is that concept? Why should someone care about this if they're using Cloudflare or any other product or service?

So, Identity and Access Management is a few concepts all tied into one.

The first bit of it is authentication, the idea that you can present yourself to a website and say you are who you say you are.

This can be done via a username, password, a biometric, 2FA, UBT.

Effectively, there is an identifier and then you validate that that identifier belongs to you.

The second portion of it is authorization. Beyond being able to identify yourself, you can show that you can do what you're trying to do.

A good way to think about this is if you show up on a construction site, you could have a high visibility vest that shows that you should be there, but you may not necessarily be there to do something appropriate.

How we generally do this on the web is having a set of policies to ensure that the right users have the right access to specific resources.

That means read, write, execute permissions on specific files on a computer or on a web service.

It could be letting out whole parts of the website.

We have identity or authentication, which is who you are, proving that we have authorization, what you can do that makes sense to make sure you can only do the right things that you should be able to do.

Why do customers care about this? If they don't, why should customers care about this?

Can you explain a little bit? What are people trying to protect against? What are they afraid of?

What are they trying to do? With identity, realistically, we're trying to cover three things.

Confidentiality, integrity, and availability.

These three things are the core of cybersecurity, and having layers of protection allow you to protect those.

Confidentiality, if people cannot log onto your site, they may not be able to see what you have hidden behind it.

Integrity, by being able to prevent access to the site in the first place, no one will be able to edit or mess with the site.

Availability, hypothetically, if they cannot log into the control plane, they cannot take it down.

With regards to identity in particular, there is something that we call least privilege that we try to preserve, and that is for a given account, you only have the appropriate access for what you need to do.

You do not grant more access such that if someone were able to take control of the account, they couldn't do more than you were originally meant to.

What this does is it minimizes the attack surface and really controls your risk.

Even if authentication as a control has broken, by being able to then restrict your authorization, prevent them from doing anything bad to a site, you minimize the amount of risk.

Got it. We have least privilege, only letting people do what they should be able to do.

If something bad happens and your account gets taken over, that limits the blast radius of the damage that an attacker can do.

That all sounds well and good. Let's move away. We've talked about the theoretical a bit here.

Now, let's take it to Cloudflare. Can you talk a little bit about, before we get into the announcement of domain scope roles, talk a little bit about what has this looked like at Cloudflare today?

What do customers have if they're not aware, especially enterprise customers today?

With regards to what we have right now at Cloudflare, we have a series of roles and what we call RBAC, or role-based authorization controls.

What that means is Cloudflare has an account where you can have multiple zones.

All of these roles are generally per product area.

You can be, for example, a web application firewall admin, and you will have access to all of the web application firewalls on your account.

We split this out into over 20 roles today, including something as big as super admin, which gives you access to effectively everything Cloudflare has to offer.

Scope down to read-only, which only allows you to view the dashboard and really check that everything is configured correctly.

Got it. That's what our customers on the enterprise side have today.

What do self -serve customers currently have? Self -serve customers have two of the many options.

They have the single super administrator, that owns the account, and then they have the ability to delegate administration privileges, which allow users to take most actions, but not anything to do with billing, or invitation, or revocation of other users.

Got it.

Going back to enterprise customers, we have all these roles. They cover a bunch of different products.

You can grant read access to various products. You can grant write access to various products, or the combination thereof.

So domain scope roles, how does that change the game?

What's new here? So domain scope roles, right now, all of our roles effectively act at the account level.

Within an account, if you have, say, five or six websites, and you give access to web application firewall, you're able to manage the web application firewall across all those properties.

By putting up domain scope roles, we are now able to, for a given site, restrict access down to that.

Got it. So as an example, let's say I have a few different websites in my account.

One of them is my super important production site, like GloveFlare.com, for example, whereas I might have some others that are testing sites, for example.

So you're saying that now, with domain scope roles, I can control who gets, in this case, web application firewall access to the production site, but I can limit that to a specific set of users while still giving more people write access to the other websites, or even still give them read access to GloveFlare.com.

Is that correct? That is correct. By having these, we can now, within an account, not have to restrict access solely at the account level, but we can grant people more permissions, but maintain the ability for you to preserve least access.

Instead of not inviting the users and only having one person deal with all production items, you can still have that person deal with all the production deployments.

However, actually grant access to your users onto the account so that they can modify the testing and the staging environments so that everyone's working off a single control plane.

Got it. I see. I see. Okay. Do you want to show us a little bit about what this looks like?

Sure. What I have here is I have a demonstration account on Cloudflare.

This is called the walkthrough account.

As you can see, I have three sites set up, walkthrough zone number one, walkthrough zone number two, and walkthrough zone number three.

What we have here is within the context of user management, what was previously available was we could solely invite users across a set of roles.

By putting in domains called roles, by clicking invite here, we are now granted with options beyond solely just the role and which user.

If we think about what access actually represents, there is a who, a what, and a how that they're going to put in this access.

I put in a specific user, let's say example at example.com.

This would be the first user. We would be able to add them onto the list.

From here, what was traditionally available was we would be able to include all domains.

This would be all of our currently existing roles that exist across the account, from the super admin down to the administrator and the administrator read-only.

Got it. This is the existing set of roles that our enterprise customers are used to seeing today, correct?

That is correct.

Everything that is available right now for our enterprise customers continues to be available at the account level when we select all domains.

Cool. Now, what we have also added is two more options.

One is within a specific domain. We can select here, we can see that the three domains that were up on the front page of this Cloudflare account, walkthrough zone number one, walkthrough zone number two, and walkthrough zone number three can be individually addressable.

Within here, we can now assign the new roles, domain DNS, which grants access to edit DNS settings for a domain and an account.

Domain administrator read-only, which preserves that read-only capability, but only at the domain level, as well as domain administrator, which effectively grants full access to that domain and some read -only access at the account-wide level.

Got it.

If in this case, taking this example, you invited this user to walkthrough zone one as a domain administrator, they would have full access to that specific domain, but what about those other two zones?

Do they get any access to that or no?

They should not get any access to the other zones whatsoever. That is what restricts the access to the other zones.

Got it. I guess this has been true of Cloudflare, but to reiterate, in this case, anything not specifically granted is default denied access to, correct?

That is correct. We are a fail-safe system. That means that unless there is an explicit grant, we should not grant access.

In addition to providing the ability to configure access solely for a specific domain, if you have one account between several lines of businesses, and each of them controls, let's say, five or six sites each, we actually have an option here for a domain group.

I have already created one called line of business one, but let's walk through the creation of a domain group.

Within the creation of a domain group, you will notice that you can click on that button, and you will see all your domains here.

We can actually assign a new name. Let's say line of business two.

Let's say line of business two solely has access to zones two and three. By being able to do this, we can create this domain group, assign users to this domain group, and effectively use it to manage access, and when we want to add a site to the domain group, all of the users within that domain group would continue to get access to that domain group.

If we were to drop a site from that domain group, it would reduce their access accordingly.

This makes it easier to manage an organization where you may have many sites and many disparate groups of users.

Got it.

In this case, if we granted domain DNS access to line of business two group, then this user gets access to both of those zones automatically, and in the future, if multiple users had access to this specific domain group, you don't have to update each individual's access policies or membership.

You can just go in and add or remove domains from that group, and they automatically get that differing access.

So the next time this user logs in, if you added another zone to it, they'd see it on the dashboard when they logged in.

Is that correct? That is correct. It should make management across these zones significantly easier, given you could have hundreds of zones, and for each of them, multiple domains still grows.

By reducing it to the single page where you can manage the whole group at a time, there should be less work overall as overhead.

I'm going to continue here with inviting the user example at example.com to the line of business two as a DNS user.

When we hit continue to summary, we will be able to see the whole creation of this invitation, the who, the what, and what level of access we want to grant them prior to hitting invite.

This allows you to validate that you have granted the right amount of access to the user prior to actually doing it.

And as we can see now, example at example .com has not accepted their invite yet, but they have been granted access to this domain group.

It states which domains they have access to specifically, and the permissions within that.

Nice. So this gives me a nice summary of sort of, you know, what's the level of access that this user has, and I assume if we in the future change the domain group, then we'd see, you know, differences in the domains listed here.

That is correct. If we were to change line of business two, let's say we were to do that right now, and add walkthrough zone one, it would add walkthrough zone one onto this list.

Nice.

One thing I'm a bit curious about is sort of, you know, if you go back to the invite flow, whether you edit this one or invite another user, we have sort of in the scope section, right, we have sort of operators and domain groups.

Like, can you talk more about sort of what are the flexibility?

We know domain groups give me a set of domains that I can pick.

You know, what is sort of the additional flexibility that this scope section really grants?

The scope section here, for now, it allows us to create relatively complex policies where we are able to, even within a domain group, exclude access to a specific domain or grant additional access to that specific domain.

An example here would be, let's say, a user in line of business two is in an administrator group where they also want limited access to the one zone that is not in line of business two.

In this case, walkthrough zone one. We would still be able to grant this without them going outside line of business two, such that when line of business two is updated, they automatically get any updates to the list of domains there.

Got it. Okay. So, you could basically say this one user, you know, should also get this extra domain access, but I don't have to add it to the domain group because I would give it to a bunch of other people in the account, which I don't want to do.

That is correct. The best way to visualize this is if you had a team where the one manager should have access to, say, the production site and everyone else and the domain group only had all the testing, staging, and pre -production domains, you could explicitly grant access to that one user.

Nice. Okay. Cool. Well, I know, but I suppose also one could use this to say, you know, grant access to all the zones in the account but remove a specific one or, you know, remove a domain group from the set of zones in the account, so you can kind of get, you know, depending on your specific needs in terms of granting access, right, you kind of get flexibility to define, you know, exactly in the easiest way the set of domains that someone should have access to, whether that's through inclusion or exclusion policies.

That is correct. A case where you may want to use a domain group as something exclusionary is if you had a set of protected domains doing the counterexample where you had all of the production domains scoped to a single production team and every other site you could manage them for domain groups and have the users in them that way, in which case you could therefore exclude a specific domain group.

I see.

Okay. So, in this case, and even if you change the first scope to be maybe like all of the domains, right, if we take that example, right, so then this is I get access to everything, but I don't get access to line of business one effectively.

That is correct. Nice.

This is really awesome because I could imagine, you know, here at Cloudflow we might use that for, you know, I have many teams have much fewer production domains than they have other domains and other domains get created, you know, all the time and so, you know, the production domains change very rarely and so you can say, well, here's, you know, our three production domains, put them in a group, you know, very few people get that level of access, but everything else that gets created, you know, no reason that that users can't have access to that stuff.

So, sometimes like, yeah, this kind of exclusionary policy is much simpler and requires a lot less upkeep from a, you know, permissions perspective because we'd like customers better set this up and not have to worry too much about it day to day.

Cool.

Anything else that you'd like to show in here? I think that is it for domain scope roles.

Look forward to a, we have a blog post and we will have enhanced documentation to teach you how to use all of these features.

We are looking in ways to grow the number of roles we have, not solely our whole account scope roles, but our domain scope roles as well.

Got it. So, if, I guess, let's ask the first, let me ask the first question.

If a customer is interested in this, you know, we announced this is generally available today, sort of what's the plan?

How can customers, can they start using it?

How do they get access? What do they need to do? So, our enterprise customers will not have to do anything.

Over the next month and a half to two months, we are expected to roll this out slowly to to the whole enterprise user set.

However, if you would still like earlier access to it, then when your rollout date comes, please reach out to your CSM and we will be able to enable your account and all of your users for these capabilities.

Got it. Very nice. Very nice.

And you talked a little bit about sort of the roles here. You know, can you give us any inclination?

I imagine some customers may be doing this and I might want X role or Y role.

Is that something coming down the pipe? If they have that feedback, what can they do?

If you have that feedback, please also reach out to your CSM and we'll get it on our feature request list.

Some of the exciting ones that we're already considering are more work on cache purge, a little bit more granularity on web application firewalls.

And as they come in, we're hoping to make these new policies and this new amount of granularity on our system available to all of the products across Cloudflare and the Cloudflare ecosystem.

Oh, so in that case, you mean sort of taking this, you know, scoping of, in this case, individual domains, but bringing that to other products that have individual resources.

Is that what you're talking about? I think the first step would be any of our products that really exist at that zone level.

They very much fit this paradigm that we're doing in scope right now.

Those will likely come first, but beyond that, we are very excited that we have an authorization system that allows us the flexibility in creating policies such that when we get to more of those products, we will be able to scope down further.

A good example would be we're looking into how we can do individual DNS records and really scope that out.

So a specific team of people has access to specific DNS records. Got it. Okay.

So in that case, you know, maybe users on my team that have access to Cloudflare, you know, can edit TXT records because they need to set up, you know, mailing redirects or, you know, domain verification for mailing services, but they want that to change something like maybe my, you know, core A or C name records that, you know, are actually routing traffic through to Cloudflare.

Yeah.

And I think as we look through our product portfolio where it makes sense, we will definitely be looking into individual products and trying to understand how teams can use them.

If you can think of anywhere that our ecosystem could use that, please reach out to your CSM with a feature request.

We would love to hear your feedback and understand your use cases for how you would like to get further authorization within our ecosystem.

Got it. Very cool. Very cool. I want to touch on a moment if, you know, if I'm not an enterprise customer and I'm looking at something like, man, this is pretty nice.

You know, I have a team of people that are managing Cloudflare, even though I'm not an enterprise customer, you know, I'm really interested in stuff.

Is there anything that we can share today about, you know, what they might be able to look forward to?

I don't know if we can share anything today, but there is definitely something coming out over the next two or three weeks.

Keep your field for all those users that are not enterprise customers.

We are hopefully going to make it easier for all of you to do least privilege across your accounts.

Got it. I got it. Okay. Okay. Okay. So it sounds like next couple of weeks, you know, GA week this week, birthday week next week.

It sounds like there might be something that we're cooking up that that's gonna, it's gonna make everyone a little bit happier.

So that's, that's good to hear.

I'm curious, anything else, you know, exciting on the IAM roadmap that, you know, is worth, worth punching up here for, for those interested, since there are, you know, interested in domain scope roles.

I think with regards to authorization, we are very excited to announce something in the next few weeks.

We also have a few projects on the authentication front.

From an authentication front, you'll notice that we have our first social login, and we are looking to expand that over the next few months.

Anywhere that we can get a password out of users' hands is less risk for both us and those users.

Got it. Yeah, absolutely.

You know, passwords are the bane of many people's existence and the, the source of, of many different issues.

For folks, you know, unaware at Cloudflare, we require everyone to use, you know, hardware keys in order to authenticate in any of our platform that has, you know, we've publicly talked about that has saved us many a time from, you know, attacks of various sorts against, against us.

And so, you know, passwords alone are no longer, and have not been for a long time, sufficient to, you know, protect your ecosystem.

If you do enough digging, you can probably find almost any of your accounts in some, one site that you sign up for has been exposed, and your password leaked in there.

So, obviously, yes.

There's a lot of important stuff that people do on Cloudflare. We want to make sure it stays secure.

PSA, if you don't have something like 2FA enabled on your account, you absolutely should get it enabled.

We support many different factors, including hardware keys.

And so, definitely want to make sure that, you know, you do what you can to protect your account.

Any other thing you, to share on the enterprise side in front of anything coming down the pipe that you, that we can talk about?

I know we can't talk about everything that's cooking in the kitchen. I, I'm looking forward to another one of these talks where we'll be able to announce a little bit more.

I, I think we do have something cooking that will make it easier beyond domain groups for users to really manage their access from a single control plane.

We understand that a lot of enterprise users really manage all of their SaaS services from a single IDP.

And we are doing something in that direction, although I don't want to give out all the details just yet.

No worries. No worries.

We won't, we won't spoil all the surprises. I got to save some for later.

Okay. Well, this has been, you know, really awesome. I know you and the team, it's been a lot of work to, to get this done, but super excited that we can get this in the customer's hands, let them start, you know, better securing their accounts.

And, you know, this is the kind of first step and, and a longer road to, to making things better.

Any, any sort of last words, parting thoughts on this before we, before we wrap things up?

I want to reiterate that if you are an enterprise customer and you would like access to this feature, we will be rolling it out with notification.

However, if you want to get it earlier, please contact your CSM to get enabled.

This does represent a step forward in our migration to new and more granular, better authorization.

And we are going to continue making strides in that direction.

And I really hope that we can delight on your security journey as you continue with LoveLayer.

Awesome. Yeah. And actually something I just thought of, you know okay, someone's looking at this and they're wondering, oh, well it just launched.

I don't know if it's going to be, you know, is it going to work?

Am I going to run into a bunch of issues? Can you share anything about sort of, you know, we've been in the beta for this for a while.

Can you share any sort of scope and how that's been and things like that? We have been in the beta for about six months at this point.

So we have thoroughly shaken out many of the use cases that users are doing.

We do have all of the existing legacy roles to make sure that we are backwards compatible in some way.

So it is expected to be nice sailing forward. Awesome. Awesome. Well, Joseph, thanks so much for taking the time to talk with me and, you know, walk through this with customers.

Very excited to, you know, to see this and glad we can finally put this in all of our customers' hands to get them going on their journey for better security.

Thank you, Garrett. It was really nice speaking about how we're making the authentication and authorization journey better.

Awesome. Thanks.

Thanks, everyone. Bye.