Getting Started with Policies

If you're new to Oracle Cloud Infrastructure Identity and Access Management (IAM) policies, this topic gives guidance on how to proceed.

If You're Doing a Proof-of-Concept

If you're just trying out Oracle Cloud Infrastructure or doing a proof-of-concept project with infrastructure resources, you may not need more than a few administrators with full access to everything. In that case, you can simply create any new users you need and add them to the Administrators group. The users will be able to do anything with any kind of resource. And you can create all your resources directly in the tenancy (the root compartment). You don't need to create any compartments yet, or any other policies beyond the Tenant Admin Policy, which automatically comes with your tenancy and can't be changed.

Note

Don't forget to add your new users to the Administrators group; it's easy to forget to do that after creating them.

If You're Past the Proof-of-Concept Phase

If you're past the proof-of-concept phase and want to restrict access to your resources, first:

Policy FAQs

Which of the services within Oracle Cloud Infrastructure can I control access to through policies?

All of them, including IAM itself. You can find specific details for writing policies for each service in the Policy Reference.

Can users do anything without an administrator writing a policy for them?

Yes. All users can automatically do these things without an explicit policy:

  • Change or reset their own Console password.
  • Manage their own API signing keys and other credentials.
Why should I separate resources by compartment? Couldn't I just put all the resources into one compartment and then use policies to control who has access to what?

You could put all your resources into a single compartment and use policies to control access, but then you would lose the benefits of measuring usage and billing by compartment, simple policy administration at the compartment level, and clear separation of resources between projects or business units.

Can I control or deny access to an individual user?

Yes. However, there are a couple things to know first:

  • Enterprise companies typically have multiple users that need similar permissions, so policies are designed to give access to groups of users, not individual users. A user gains access by being in a group.
  • Policies are designed to allow access; there's no explicit "deny" when you write a policy.

If you need to grant access to a particular user, you can add a condition to the policy that specifies the user's OCID in a variable. This construction restricts the access granted in the policy to only the user specified in the condition. For example:

allow any-user to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'

For information about using conditions and variables in policies, see Conditions.

If you need to restrict a particular user's access, you can:

  • Remove the user from the particular group of interest
  • Delete the user entirely from IAM (you have to remove the user from all groups first)
How do I delete a user?

First ensure the user isn't in any groups. Only then can you delete the user.

How can I tell which policies apply to a particular group or user?

You need to look at the individual statements in all your policies to see which statements apply to which group. There's not currently an easy way to get this information.

How can I tell which policies apply to a particular compartment?

You need to look at the individual statements in all the policies in the tenancy to see if any apply to the particular compartment. You also need to look at any policies in the compartment itself. Policies in any of the sibling compartments cannot refer to the compartment of interest, so you don't need to check those policies.