Managing Roles and Groups

In this section, we are going to talk about managing roles and groups. We’ve already mentioned quite a bit about groups and how the users get allocated to these groups. But it’s also very important to understand in the cloud environment, all the policies and everything else gets put into the different groups that we have. So any authorizations or any of the rules that you have are going to go into the groups. In the next section, we’ll also look on how to include those groups and roles from the Cloud Identity Service.

But first let’s take a look at groups. So I’m here in my Oracle Cloud Dashboard. And I’m going to go down to Identity again. And I’m going to go to Groups. Now you’ll see that we have several groups already created. We have certain groups already mapped back to our Cloud Service, which we’ll look at again.

And so here we’re going to look at creating a group. So I’m going to create a group for our auditors to come in. And I already have an auditors one group. I’m going to create an auditors admin so they can review everything and inspect everything in the tenancy that we have. So they’re not going to be able to do the different tasks, but they can inspect it and review it. And we’re going to have tenancy. And we’re going to submit this as a group.

Great, now we have created a group. These groups here all need certain policies. And as we talked about before, the administrators have certain policies to be able to perform the different tasks and configurations in the Oracle Cloud. And that’s what gets created by default. You’ll see that I’ve created several groups here with database admin, developers, ABC. Those are groups that we can add users to and also map our users from our Federation environment.

But first let’s go look at policies. So I want to create a policy that is set up for our auditors. So auditors, auditors admin– these are auditors that are going to review everything. These are auditors inspectors. And we’re going to add a policy, allow group auditors to inspect all resources in the tenancy.

So it’s also important to realize that, in the compartment, that you are in the root compartment when you’re doing this. Otherwise, they will not be able to inspect everything in the tenancy. And you’ll have to do and set things at the compartment level.

So we can go ahead and create this policy. And you’ll see that this auditors inspectors, auditors admin group was created with one statement that provides them the access to do the inspection of our cloud environment. Now we have to go back to our groups. And we look at the auditors admin. And we do not have any users in that group, so we’re going to have to add our users.

So we’re just going to select our users. We can add Michelle into this group. This is a local account for our cloud admin. So this is not a federated account. And they can be part of this group to be able to inspect and audit our cloud environment.

So there are several different policies that you can set up. For example, I want to create a group for my backups, because I only want the backup admins to be able to backup our cloud environment, but not do anything else. So I could submit that. And now I have a group for backups. It’s important to create the group before adding the policies, because when we create our policies, we add that group in our statement.

So this is backup, admin policy. And it provides the backups. And if you go into the statement, you say allow group backup. So I’m going to allow group backup admins.

And you’ll see that’s the group that we just created. And so this is already tagging the policy to that group. And so we’re adding the backup admins– backups admin to use volumes in tenancy. And this will allow them to have access to those volumes and create their backups. So then any one that I add to this group, backups admin, they will have permissions to use the tenancy as planned.

So these policies are going to be important. And you can create these policies based on the tenancy or based on the compartments that we have. And if we look at the compartments really quick, we have the root compartment. I have a sandbox that I use for developers. I have a couple other cloud user development that I’m looking at, projects. And so there is different compartments that I can have. I can also create one for production, one based on a line of business, for example, and set these compartments. And then I can actually create the policies based on the compartments.

So if I look at the policies here, I can create a policy to manage keys in compartment sandbox. So I might have a set of DBAs that are going to manage that security piece. And you can see how it is not for the whole tenancy, but just for those compartments that we created.

So another way to do that is also looking at compartment IDs– and any of the databases that come in there, what we are going to manage. So we’re going to look at dynamic groups here. So let’s create a dynamic group.

And we’re going to create a dynamic group for DBA testing. And we’re going to setup a rule for them. We’re going to set setup where instance compartment ID equals– and I grabbed the OCI ID for my compartment for the sandbox. And that’s going to allow them just to go in to that compartment.

So if anything else was created in there, or any other rules that are defined for that apartment, they automatically get added to this dynamic group. Instead of specifically saying what type of information is there, or if there is any other rules that get added or policies, I don’t have to state that for every policy– but adding this as a compartment so any of the matching rules would apply, thus creating a dynamic group. And in this dynamic group, I can add users, just as I would in our regular groups.