Dec 5, 2023
00:00
Welcome to the Oracle University Podcast, the first stop on your
cloud journey. During this series of informative podcasts, we’ll
bring you foundational training on the most popular Oracle
technologies. Let’s get started.
00:26
Nikita: Hello and welcome to the Oracle University Podcast. I’m
Nikita Abraham, Principal Technical Editor with Oracle University,
and with me is Lois Houston, Director of Innovation Programs.
Lois: Hi everyone. Thanks for joining us for this Best of 2023
series, where we’re playing you six of our most popular episodes of
the year.
00:47
Nikita: Today’s episode is #3 of 6 and is a throwback to a
conversation with Rohit Rahi, Vice President of CSS OU Cloud
Delivery, on Identity and Access Management, which is one of OCI’s
top security features. So, let’s get straight into it.
01:03
Rohit: IAM stands for Identity and Access Management service. It's
also sometimes referred to as fine-grained access control or
role-based access control service.
There are two key aspects to this service. The first one is called
authentication, or also referred to as AuthN. And the second aspect
is referred to as authorization or also referred to as AuthZ.
Authentication has to deal with identity or who someone is, while
authorization has to deal with permission or what someone is
allowed to do.
01:37
Rohit: So basically what the service ensures is making sure that a
person is who they claim to be. And as far as authorization is
concerned, what the service does is it allows a user to be assigned
one or more pre-determined roles, and each roles comes with a set
of permissions. Now, there are various concepts which are part of
this service or various features which are part of this service,
starting with identity domains, principles, groups, dynamic groups,
compartments, et cetera. Now identity domains is basically a
container for your users and groups. So think about this as a
construct which represents a user population in OCI and the
associated configurations and security settings.
02:30
Lois: So, how does this work in practice?
Rohit: Well, what we do first is we create an identity domain, and
then we create users and groups within that identity domain. And
then we write policies against those groups, and policies are
scoped to a tenancy, an account, or a compartment. And of course,
the resources are available within a compartment. And again,
compartment is kind of a logical isolation for resources. So this
is how the whole service works.
03:03
Rohit: And users and the groups, authentication is done by common
mechanisms like username and password, and policies is basically
where you provide this role-based access control. So you put these
groups in one of the pre-determined roles, and then you assign some
permissions against those roles. So this is how the service works
in a nutshell.
Now anything you create in the cloud, all these objects, whether
it's a block storage, it's a compute instance, it's a file storage,
it's a database, these are all resources. And if these things are
resources, there has to be a unique identifier for these resources,
else how are you going to operate on these resources? So what OCI
does is it provides its own assigned identifier, which is called
Oracle Cloud ID, OCID. You don't have to provide this. We do this
automatically for all the resources.
04:02
Nikita: Thanks for that rundown, Rohit. Another feature of OCI is
compartments, right? Can you tell us a bit about compartments?
Rohit: When you open an account in OCI, you get a tenancy. That's
another fancy name for an account. And we also give you a Root
Compartment. So think of Root Compartment as this logical construct
where you can keep all of your cloud resources. And then what you
could do is, you could create your own individual compartments. And
the idea is, you create these for isolation and controlling access.
And you could keep a collection of related resources in specific
compartments. So the network resource has-- a network compartment
has network resources, and storage compartment has storage
resources.
04:46
Rohit: Now, keep in mind, Root Compartment, as I said earlier, can
hold all of the cloud resources. So it can be sort of a kitchen
sink. You could put everything in there. But the best practice is
to create dedicated compartments to isolate resources. You will see
why. Let me just explain.
So first thing is, each resource you create belongs to a single
compartment. So you create a virtual machine, for example. It goes
to Compartment A. It cannot go to Compartment B again. You have to
move it from Compartment A, or delete, and re-create in Compartment
B. Keep in mind, each resource belongs to a single
compartment.
05:21
Rohit: Why you use compartments in the first place is for
controlling access and isolation. So the way you do that is, you
have the resources, let's say in this case a block storage, kept in
Compartment A. You don't want those to be used by everyone. You
want those to be used only by the compute admins and storage
admins.
So you create those admins as users and groups, write these
policies, and they can access these resources in this compartment.
So it's very important. Do not put all of your resources in the
Root Compartment. Create resource-specific compartments, or
whichever way you want to divide your tenancies, and put resources
accordingly.
06:00
Lois: Now, how do resources interact if they are in different
compartments? Do they all have to be in the same
compartment?
Rohit: Absolutely not! Resources in one compartment can interact
with the resource in another compartment. Here, the Virtual Cloud
Network is-- the compute instance uses the Virtual Cloud Network,
but these are in two different compartments. So this is absolutely
supported. And it keeps your design much cleaner.
Keep in mind that resources can also be moved from one compartment
to another. So in this example, Compartment A had a virtual
machine. We can move that from Compartment A to Compartment B.
Another concept, which is very important to grasp is the
compartments are global constructs, like everything in identity. So
resources from multiple regions can be in the same compartment. So
when you go to Phoenix, you see this compartment existing. You go
to Ashburn, you see the same compartment.
06:55
Rohit: Now, you can write policies to prevent users from accessing
resources in a specific region. You could do that. But keep in
mind, all the compartments you create are global, and they are
available in every region you have access to. Compartments can also
be nested. So you have up to six levels nesting provided by
compartments. You would do this again because this can mimic your
current design, whether it's your organizational design or whether
it's your ID hierarchy. You could create nested compartments. It
just helps keep your design cleaner.
07:32
Rohit: And then, finally, you could set quotas and budgets on
compartments. So you could say that, my particular compartment, you
cannot create a bare metal machine. Or you cannot create an Exadata
resource. So you could control it like that. And then you could
also create budgets on compartments. So you could say that, if the
usage in a particular compartment goes beyond $1,000, you'd get
flagged, and you get notified. So you could do that.
So that's compartments for you. It's a very unique feature within
OCI. We believe it helps keep your tenancies much better organized.
And it really supports your current ID hierarchy and
design.
08:12
Boosting your professional reputation is now easier than ever.
Oracle University Learning Community is a collaborative, dynamic
community that gives you the power to create your own personal
brand. Achieve champion levels and acquire badges. Get inducted
into the Hall of Fame. Become a thought leader.
If you are already an Oracle MyLearn user, go to MyLearn to join
the community. You will need to log in first. If you have not yet
accessed Oracle MyLearn, visit mylearn.oracle.com and create an
account to get started.
08:53
Nikita: Welcome back! So Rohit, can you tell us a little bit about
principals?
Rohit: A principal is an IAM entity that is allowed to interact
with OCI resources. There are two kinds of principals primarily in
OCI. One is your users. Think about people who are logging on to
your console or using your CLI or SDKs, users… human beings
actually using your cloud resources. And then the resources
themselves can be principals. So a good example of a resource
principal is an instance principal which is actually an instance
which becomes a principal, which means that it can make API calls
against other OCI services like storage.
09:34
Rohit: Also, when we talk about principles we have groups. And
groups are basically collection of users who have the same type of
access requirements to resources. So you can have a storage admin
group where you could group all the human beings who are storage
administrators and so on and so forth.
So let's look at some of the details, starting with authentication.
Authentication is sometimes also referred to as AuthN.
Authentication is basically figuring out are you who you say you
are. And the easiest way to understand this is all of us deal with
this on everyday basis. When you go to our website and you provide
your username and password to access some of the content, you are
being authenticated.
10:15
Rohit: There are other ways to do authentication. The one common
for cloud is API Signing Keys. So when you are making API calls,
whether you're using the SDK or the CLI, you would use the API
Signing Keys which use a public private key pair to sign these APIs
calls and authenticate these APIs calls. It uses an RSA key pair,
with both a public key and a private key.
There is also a third way to do authentication, and that's based on
authentication tokens. And these are Oracle-generated token
strings. And the idea here is you can authenticate third-party APIs
which don't support OCI authentication model.
10:56
Lois: So, then, what are authorizations?
Rohit: So authorization deals with permissions and figuring out
what permissions do you have. In OCI, authorization is done through
what we call as IAM policies. And policies, think about these as
human readable statements to define granular permissions.
Remember, policies can be attached to a compartment or they could
be attached to a tenancy. If they're attached to a tenancy, it
applies to everything within that tenancy. If it's applied to a
compartment, it applies to only the resources within that
compartment.
11:33
Rohit: The syntax is always you have to start with an allow.
Everything is denied by default, so you don't really have to write
a deny statement. So you say allow group_name. A group is basically
a collection of users. So you cannot write a policy on individual
users, you always operate at a group level. To do something,
there's a verb. On some resources, there's a resource-type and
there's a location.
Location can be a tenancy. Location can be a compartment. And you
can make these policies really complex with adding conditions.
So just to give you an idea of what the verbs might look like.
There are four levels of verb. There is a manage, there's a use,
there's a read, and there's a inspect. And as you go down, these
become additive.
12:17
Rohit: So manage basically means you can manage your resources, use
basically means you can read but you could not do things like
update and delete and so on and so forth. And you can read more on
the documentation. Resource type basically can be all resources,
meaning everything in your account, or it could be compute
resources, database resources, whatnot, all the resources you
have.
Now, you could operate at a family level, which is meaning all the
entities within that resource family, or you could even go very
granular. So you could say that in compute, I just want somebody to
operate on the instances, but not work on the instance images. So
you could actually do that.
So this is how you would write a policy.
12:58
Nikita: For more on OCI, please visit mylearn.oracle.com, create a
profile if you don’t already have one, and get started on our free
training on OCI Foundations. Taking this training will help you
advance and future-proof your career and prepare you for our OCI
Foundations Associate exam.
Nikita: We hope you enjoyed that conversation. Join us next week
for another throwback episode. Until then, this is Nikita
Abraham...
Lois: And Lois Houston, signing off!
13:27
That’s all for this episode of the Oracle University Podcast. If
you enjoyed listening, please click Subscribe to get all the latest
episodes. We’d also love it if you would take a moment to rate and
review us on your podcast app. See you again on the next episode of
the Oracle University Podcast.