What is Oracle Cloud Infrastructure Identity and Access Management?
Oracle Identity and Access Management (IAM) allows you to securely control access to all of your cloud resources.
What are the key terms and concepts of Oracle Identity and Access Management?
The key concepts of IAM are:
- Compartment - A logical container for your cloud resources. Administrators within an account can create one or more compartments to organize and manage resources within their account. You might use compartments to:
- Meter usage separately for distinct business units (e.g., for chargeback purposes)
- Separate your software development environments (e.g., dev, test, production)
- Simplify permission management (allow certain employees full or partial access to specific compartments)
- Minimize the set of resources visible to certain sets of users
- Root compartment - The top level compartment within your account. The root compartment is created for you automatically when your account is provisioned.
- User - An entity that can be authenticated. A user can be either a person or a machine account. Each user has a unique name in your account and a globally unique identifier. Users can be given passwords to access the web Console and keys to access the services through the APIs.
- Group - A set of users. Groups are used to simplify access management. For example, software developers can be grouped together as members of a "developers" group, which allows them to read, write, and modify code. A single user can be a member of multiple groups.
- Policy - A document that specifies who can access which Oracle Cloud Infrastructure resources your company has, and how. A policy is comprised of policy statements. Multiple policies comprise a policy corpus.
What is unique about Oracle Cloud Infrastructure's approach to identity and access management?
With Oracle Cloud Infrastructure IAM, you can leverage a single model for authentication and authorization across all Oracle Cloud Infrastructure services. Oracle IAM makes it easy to manage access for organizations of all sizes, from one person working on a single project to large companies with many groups working on many projects at the same time, all within a single account. Resource management and authorization can happen at the account level or at the compartment level, while still allowing central auditing and billing.
Oracle IAM was built from the ground up to allow you to enforce the security principle of least privilege -- by default, new users are not allowed to perform any actions on any resources. Administrators can then grant each user only the access appropriate for that specific user.
Are changes to users, groups, compartments, and policies recorded for debugging and auditing purposes?
Yes. To support enterprise requirements for auditing and compliance, all changes are recorded and can be made available to you at no additional cost.
How do I get started with Oracle Identity and Access Management?
Oracle IAM is enabled by default at no additional charge. The very first user in your account is the default administrator. All subsequent users are created through the IAM service, where you explicitly grant them privileges to interact with specified cloud resources.
What problems do compartments solve?
A compartment is a secure logical container within your account used to host your infrastructure resources (such as compute, storage, and network), along with a set of access management policies for these resources. Compartments allow you to logically organize your cloud resources to support a wide variety of use cases.
The following are a few common ways to use compartments to:
- Separate your software development environments for simple administration. For example, you might have separate compartments for dev, test, and production; or, you may have separate compartments to support blue/green deployment.
- Simplify permission management. For example, you might create a separate compartment for your networking resources (VCNs, subnets, internet gateways, and so on), and then allow only network administrators to access that compartment.
- Meter usage separately for distinct business units in order to properly charge those business units for their cloud resource consumption.
- Minimize the set of resources visible to certain sets of users. For instance, you might want to have a separate compartment for your Finance team that is only visible to certain employees.
Can compartments contain resources in multiple Availability Domains?
Yes. Compartments are a logical groupings of resources distinct from the physical constructs of Availability Domains. An individual compartment can contain resources across Availability Domains.
How are compartments used for access control?
All policies are attached to a compartment, which could be either the root compartment or a child compartment. Each policy consists of one or more policy statements that follow this basic syntax:
Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>
Policy statements allow you to use compartments to simplify permission management; for instance, you can write a policy that allows the group HRAdministrators to manage all resources in the compartment HRCompartment.
Can I delete compartments?
Yes, you can delete compartments.
Can I move entire compartment trees and their included resources?
No, at this time you cannot move entire compartments trees and their included resources.
Can I move a compute instance, or other resource into another compartment?
No, at this time you cannot move resources from one compartment into another. Currently, we recommend that you create new resources in the required compartments.
Can I create a hierarchy of compartments?
Yes, you can create a hierarchy of compartments by nesting them. With hierarchical or nested compartments, the system administrator is able to organize resources and enable lower-level administrators to do the same, while still retaining full visibility and control via policy.
How many levels deep can you nest compartments?
The maximum depth of a nested compartment is six.
Do policies on a higher-level compartment apply to a sub compartment?
Yes, policies on higher-level compartments do get inherited by sub compartments.
Am I able to track costs and usage by compartments?
Yes, you can track costs and usage by compartments in My Services.
What is the root compartment?
For each account, Oracle Cloud Infrastructure automatically creates a top-level compartment known as the root compartment. Much like the root folder in a file system, the root compartment behaves exactly like its child compartments, except for a few special characteristics:
- Because permissions are hierarchical, group permissions in the root compartment will apply to all child compartments. For example, if group NetworkAdmins is given permission to manage Virtual Cloud Networks (VCN) in the root compartment, that group will be able to manage VCNs in all compartments.
- Currently, all users and groups are created inside the root compartment. Policies can be used to grant them access to only specific child compartments.
Note: Currently, you can create additional compartments only within the root compartment, and not within other compartments.
When should I create resources in the root compartment and when should I create them in a child compartment?
Generally, resources should be created in a compartment that is not the root compartment. It is best to design your compartment hierarchy before you begin creating compartments and resources. Currently, resources cannot be moved from one compartment to another, and compartments cannot be edited or deleted.
What can a user do?
A user is someone who can successfully authenticate against Oracle IAM, and who has sufficient privileges to either consume or manage cloud resources within your account. Administrators can create one or more users within their account, and assign them to groups in order to give them permissions to resources in specific compartments.
Who is able to create and manage users?
Your account is provisioned with a single user: the default administrator, and a single group: Administrators, of which the default administrator user is a member. This group (Administrators) has full access in your account. This special user (default administrator) must create any additional users, or grant permission to other users to create new users.
What access does a new user have upon creation?
By default, a new user does not have permission to use any resource or service within your account – all permissions must be explicitly granted. This approach allows you to adhere to the security principle of least privilege whereby you grant each user only the access required for that specific user. You must either explicitly add the user to an existing group or create a new group for them, and then assign appropriate permissions to that group through a policy.
Can I enable and disable user access?
Currently, you cannot disable user access. However, you can reset passwords or remove keys.
How can I rotate credentials?
You can automate resetting passwords, changing keys, or editing users and group memberships through the REST API and SDKs.
What is a group?
A group is a collection of users who need similar access privileges to either use or manage a specific resource within your account. Users can be in multiple groups. Permissions are additive. For example, if membership in one group allows a user to use compute instances, and membership in a second group allows that user to manage block volumes, then the user is permitted to manage both instances and block volumes.
Administrators write policies that specify groups (not individual users) with the required access they need, whether to a specific compartment or the account. Administrators then add users to the appropriate groups.
Can I have multiple Administrators?
Yes. Your account is provisioned with a single default administrator who belongs to an Administrators group within your root compartment. This group has full privileges to create and manage all Oracle Cloud Infrastructure resources in your account, including users, groups, policies, and compartments, as well as all other cloud infrastructure resources within any compartments. You can add additional users to this Administrators group.
What is a policy?
A policy is a document consisting of descriptive policy statements that grant specific permissions to groups of users. They are written with an easy-to-understand SQL-like syntax. Example policies might enforce:
- System Administrators can "terminate" or "reboot" your bare metal compute instances.
- Network Administrators can fully administer all network-related infrastructure resources.
- IT Administrators can create users and edit group memberships
Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name> [where <conditions>]
Allow group Developers to use instances in compartment ProjectA
- "group_name" is the name of the group being granted permissions.
- "verbs" are actions you can take on resources, for example: inspect, read, use, or manage.
- "resource-type" is the cloud resource to which permissions are being granted. Example resource-types include: instances, volumes, and route-tables.
- "compartment_name" is the name of the compartment in which the resources are organized.
- "conditions" are further specifications that narrow the scope of the policy statement. Examples include: "where request.user.id=target.user.id" or "where target.group_name != Administrators".
Are policies for the root compartment inherited by child compartments?
Yes. A policy granting permissions in the root compartment automatically grants the same permissions for all child compartments. For example, the following policy gives permission to all users in the group "InstanceAdmins" to manage instances in the root compartment as well as all child compartments:
Allow Group InstanceAdmins to manage instances in tenancy
Can policies be limited to specific compartments?
Yes. Each policy is "attached" to a compartment. Where you attach it controls who can then modify it or delete it. If you attach a policy to the root compartment, then anyone with access to manage policies in the root compartment can change or delete it. If you instead attach the policy to the compartment, then anyone with access to manage policies in that compartment can change or delete it. In practical terms, this means it is easy to give compartment administrators (i.e., a group with access to "manage all-resources" in the compartment) access to manage their own compartment's policies, without giving them broader access to manage policies that reside in the account.
What is identity federation in Oracle Cloud Infrastructure?
Identity federation is a mechanism to delegate user management for your Oracle Cloud Infrastructure tenancy to another entity called an Identity Provider or IdP. This is useful to companies that have an existing Identity system they would like to use, rather than creating and maintaining a new set of users. Federation requires a one-time configuration between Oracle Cloud Infrastructure and the IdP known as a Federation Trust.
What are federated users?
Federated users (external identities) are users you manage outside of Oracle Cloud Infrastructure (for example, in your corporate directory), but to whom you grant access to your Oracle Cloud Infrastructure account. They differ from Oracle Cloud Infrastructure users, which are created and maintained in your Oracle Cloud Infrastructure account.
Can federated users access the Oracle Cloud Infrastructure Console?
Yes. Federated users can access the Oracle Cloud Infrastructure Console.
Can federated users access the Oracle Cloud Infrastructure SDK and CLI?
Currently, Oracle Identity Cloud Service and Okta federated users can access the Oracle Cloud Infrastructure SDK and CLI.
What actions can Oracle Cloud Infrastructure users perform in the Console that federated users cannot perform?
Federated users cannot change nor reset their passwords in the Oracle Cloud Infrastructure Console.
How do I control what a federated user is allowed to do when signed-in to the console?
You use the same Oracle Cloud Infrastructure policies to manage federated users that you use to manage native users. You map roles and groups in your Identity Provider to groups in Oracle Cloud Infrastructure. When a federated user logs in, the Oracle Cloud Infrastructure Console then applies policies based on their Oracle Cloud Infrastructure group membership, just as with native users. See the documentation for examples.
A single role or group in your Identity Provider can be mapped to multiple Oracle Cloud Infrastructure groups. Also, multiple roles or groups in your Identity Provider can be mapped to a single Oracle Cloud Infrastructure group.
How many federated users can I give access to the Oracle Cloud Infrastructure Console?
There is no limit to the number of federated users who can be given access to the console.
Which Identity Providers do you support?
Currently, we support Oracle's Identity Cloud Service (IDCS), Microsoft Active Directory Federation Services (AD FS), Okta, and any other SAML 2.0 compliant identity provider.