All right, it is time for the lesson
on role-based access control.
In this lesson, we're going to talk
about how we secure Azure Data Lake through RBAC,
or role-based access control,
and access control lists, or ACLs.
Now, if you have had any certification,
if you've done the AZ-900, the DP-900,
or any Azure certification, you should have some familiarity
with role-based access control. But we'll do a quick review
so that you understand the basics,
and then we'll jump in
and we'll talk about access control lists, or ACLs,
which you probably have a little bit less familiarity with.
But we'll talk about what you need to know for the DP-203.
And then of course, we'll finish up
by jumping into the portal, and I'll show you
where you would be able to find role-based access control.
So with that, let's talk about RBAC.
It all starts with a security principal.
Now, a security principal is just a representation.
It's the gatekeeper, if you will.
And basically, what happens is it requires
that any users or service principals
have to go through this security process.
So it all starts with this security principal.
So this is going to be a guest,
or an employee, or an application, a service principal
that's trying to access another resource within Azure.
Okay? So it starts with that security principal.
Then, we talk about a role definition.
So now that we know who's trying to access,
we need to talk about what it is that we want them to do.
So are they an owner? Are they a contributor?
Can they only read things but not edit anything?
Can they do nothing or next to nothing?
So this is the role definition,
and it defines what the security principal,
or the user in step 1, is able to do.
The third piece is the scope.
So, where can they do this thing?
So, it may only apply to Azure Synapse,
or it may only apply to a SQL Database,
or it might apply to an entire resource group.
So what we do is we take that security principal,
and that role definition, and that scope,
and we marry all 3 of those together
into a role assignment.
So this role assignment, which is basically RBAC,
role-based access control, allows us to identify a user,
then identify what they should be able to do,
and then define where they should be able to do that,
and put all of that together into RBAC.
So, with that foundation, let's talk a little bit
about access control lists.
So access control lists are simply a way
to give more detailed or a finer-grain access
to directories and files that you may have.
Now, it is important to note before we go too far into this,
the way that ACLs are evaluated.
So, we start off with an RBAC.
That is the primary assignment.
So if you grant access to something in RBAC,
then access has been granted.
If you don't give access to something in RBAC,
then we'll look at access control lists
and decide if, "okay, well you still can have access".
So at a high level,
we could say for RBAC, you don't have permission
to access anything in SQL Database.
However, in our access control list,
but we could say that you have access
to this 1 folder or 1 file.
So it's a little bit of a finer grain than RBAC is.
Now, access control lists basically associate
a security principal with an access level.
So we talked the first step about RBAC,
and that's how we identify the user
or the application that's trying to get access,
and then we marry that with an access level
to decide whether or not you should be able
to access this file or this folder, whatever.
Now, with ACL, each file or directory in a
Blob Storage is going to have its own ACL.
And so we can go in there
and we can determine access for each file or directory.
And we can programmatically set this,
or we can also set this in the portal.
And there's a couple of different permissions.
And I actually wanted to pull this up
to show you kind of the shorthand of what this looks like.
So, we have
RWX
and dash.
The R stands for read.
So if I have R permission, that's read only.
If I have W, that is write, so I can write to a file.
And then the X is execute.
So, this was something that was stood up for Gen1.
If we're talking about a Data Lake Gen2,
it really means nothing, but the X stands for execute.
And the execute in the older version would just allow you
to move through child folders within a larger directory.
But that's what RWX is.
Now, the R and the W, obviously,
are going to be the most utilized.
And then finally we have the dash,
the dash just means you don't have access.
So you can see here from this permission list,
the very top would give you access
to read, write, and traverse.
The one below that, the R-X, would only give you permission
to read or go through subdirectories.
The one below that would only give you permission
to read things in the primary directory,
but not any subdirectories.
And then the bottom one, the ---,
gives you absolutely zero permission to do anything.
So that's the shorthand version.
You'll see that when we jump into the portal
for RBAC as well, the read and write,
but that is the shorthand version
when you're talking about ACLs.
So with that, we should have the basics down
for RBAC and ACLs,
at least as far as the DP-203 is concerned.
So let's go ahead and jump over
into the portal and take a look at RBAC and ACL.
Okay, so now we find ourself
in the Azure portal in a storage account.
And what I've done is I've clicked on Access Control,
or IAM, which is identity access management.
And within here, I can actually work with RBAC.
So we talked about roles, for instance.
So I can click on Roles here,
and you can see that there are a whole lot
of roles that are already configured.
And if I was to click on View here, again,
I can also go to JSON and I can see a JSON version
of what we were looking at just a second ago.
So I can come in here and I can see that this is the role.
This is the description of what the role is.
And then you can see actions and things.
So actions are things that I can do,
notActions are things that I can't do.
And then I can assign that
to a whole bunch of different places,
and then I can also assign that to users as well.
So with all of that, that's how RBAC works in Azure.
Let's also take a look at ACLs.
So if I jump into one of my containers, for instance,
I can click on this container
and then this individual CSV file.
And if I was to click on this over here on the right,
the 3 dots, I can come down
to Manage access control list, or Manage ACL,
and you can see then that I can assign users
the ability to read, write, and execute, that RWX.
And then the nothing here, that would be our dashes.
All right?
That simple.
I would just click on what I want, click on the Save button,
and then that would give me access to do something
within Azure.
So a couple of key points to remember.
First, RBAC is a core concept.
This is something that you have to think about
regardless of the service, whether you're talking
about data, or operations, or it doesn't really matter.
You're going to need
to understand identity access management and RBAC.
Role definitions should be a core cloud consideration.
So this is not just for your employees,
but also for your contractors.
You need to think through the different types
of roles that you're going to have,
and figure out what they should have access to.
This is a really easy way to manage security
and manage who has access to what
based upon role definitions.
So with that, this is what you need to know
for the DP-203.
Now, we did a fairly high-level walkthrough
because 1, this should be a review,
and 2, this is a data engineering course,
it is not a security course, nor a security certification.
So for the DP-203, this should be what you need to know
in order to move forward.
So with that, we're going to move forward,
and I'll see you in the next lesson.