Users, roles, and scopes

Identity & Access Management controls who can sign in to your organization and what they can do in it. What a member or a service account can do comes from its role assignments: a role, given to the principal, at a scope. This article explains each of these parts.

Organization and scopesCopy Anchor Link

Your organization, also called the tenant, holds one or more subscriptions, and each subscription holds projects. Resources, such as instances and volumes, live in projects. See Tenants, subscriptions, projects, and regions.

Members, service accounts, and custom roles belong to the whole organization. A role assignment applies at one of two scopes:

• A subscription. The assignment applies to the subscription and to every project in it.
• A project. The assignment applies to that project only.

For example, a role assigned on the subscription Production applies in its projects web-platform and data-platform. The same role assigned on web-platform applies only there.

PrincipalsCopy Anchor Link

A principal is an identity that can be given roles.

• Members are people. They sign in to the console with their email address and password, and with a code from an authenticator app when two-factor authentication is on. You add members by invitation. See Invite and manage members.
• Service accounts are machine identities for automation. They don't sign in to the console; they call the REST API with keys whose secrets start with sak_live_. See Service accounts and API tokens.

An API token, with a secret that starts with pc_live_, isn't a principal of its own. It acts as the member who created it, limited to the permission scopes selected for the token.

Roles and permissionsCopy Anchor Link

A role is a set of permissions. For each permission resource, such as Compute / Instances, Networking, or Identity & Access, the role grants None, Read, or Manage. Read lets the holder view the resource, and Manage lets the holder view and change it.

• Built-in roles. Owner, Contributor, Reader, and Billing Operator. You can't change them.
• Custom roles. Roles you define, from scratch or by cloning another role. For example, a custom role can grant Manage on Networking and Load Balancers, and Read on everything else.

See Use built-in and custom roles.

Role assignmentsCopy Anchor Link

A role assignment gives a principal a role at a scope: for example, the Contributor role to a member on the project web-platform. A member or a service account can have several assignments, with different roles at different scopes.

On every request, the platform checks the principal's role assignments that apply to the project, and allows the request only if they grant the access it needs. When several assignments apply, they add up: for each permission resource, the highest level from any of them applies. For example, a member who is a Reader on the subscription Production and a Contributor on the project web-platform can change resources in web-platform and view the resources in the other projects of Production.

Some billing resources belong to the whole subscription: invoices, payment methods, credits, and commitments. For these, only assignments on the subscription count: a role assigned on a project gives no access to them, even the Owner role. Cost Explorer, the cost summary, and budgets also work with a role assigned on a project, and then cover only that project.

Who can change assignments, and what else they decide:

• Granting. To assign a role at a scope, you need the Owner role, or a custom role with Manage access to Identity & Access, at that scope; for the subscription, it must be granted on the subscription itself. There, you can grant only roles that rank no higher than your own and whose permissions you hold yourself. A custom role can be assigned only at the scopes it allows.
• Organization-wide settings. Requiring two-factor authentication and switching OpenStack API access on or off take the built-in Owner role on the subscription. A custom role, or the Owner role on a single project, isn't enough.
• Project creation. Creating projects in a subscription takes the Owner role on the subscription or a separate project creation grant. See Allow a member to create projects.
• OpenStack access. A principal's role in a project also sets which OpenStack roles its application credentials can have there. See What is OpenStack API Access?

AuthenticationCopy Anchor Link

• Password. Members choose their own password when they accept their invitation.
• Two-factor authentication. Members can add a code from an authenticator app to their sign-in, and an owner can require it for members. See Enforce two-factor authentication.
• Sessions. Every signed-in browser has a session that you can sign out. See Manage sessions.
• Step-up verification. A few sensitive actions ask for a fresh code from your authenticator app, even in an open session. See Step-up verification.

Related tasksCopy Anchor Link

• Invite and manage members
• Use built-in and custom roles
• Enforce two-factor authentication
• Service accounts and API tokens