Data breaches occur more often than we’d like them to. As businesses embrace remote work practices, IT resources are more at risk than ever before. Oracle Identity and Access Management (IAM) is an essential tool for protecting enterprise resources against cybersecurity threats. Join Lois Houston and Nikita Abraham, along with Rohit Rahi, as they examine IAM and the key aspects of this service, and discuss how you can control who has access to your resources.
Special thanks to Arijit Ghosh, Kiran BR, Rashmi Panda, David Wright, the OU Podcast Team, and the OU Studio Team for helping us create this episode.
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.
