Roles and permissions

Authorization is decided in four scopes:

Scope	Governs	Where it is set
Platform administration	The installation itself: admin dashboard and admin API	Admin roles, in the dashboard
Realm	Whether a user may sign in, and whether they may create organizations	The realm's default role for new users, or a provider's claim mappings
Organization	Members, projects and billing	The member's organization role
Project	Membership of one project	Owner or Member, per member

Platform administration stands apart from the other three, which nest: a project sits in an organization, which sits in a realm. Each scope narrows what the one above it allowed.

What a member may then do to a server or a volume is decided by OpenStack, from the roles OSIE granted them on the Keystone project — covered in Project membership in OpenStack below.

Platform administration

Administrators sign in to the admin dashboard. Their role is a set of permission keys of the form admin:<area>:<action>, matched by pattern, so admin:project:* covers every action in the project area and admin:* covers everything.

Role	Covers
SUPER_ADMIN	Everything, including roles, permissions and platform configuration
ADMIN	Day-to-day administration: users, organizations, projects, billing, clouds, integrations
BILLING_ADMIN	Billing configuration, invoices, transactions, credits and price plans
SUPPORT	Read access across the platform, plus credential assistance for users
VIEWER	Read-only

Custom roles are created from the same permission catalogue when the built-in ones do not fit. The catalogue is also what scopes an API secret — an integration key is granted permissions individually, so a pipeline can be restricted to exactly the endpoints it calls.

An administrator role stays on the platform side. It grants nothing inside a customer's organization or project, and no OpenStack privileges.

Realm

A realm role decides whether someone may use the realm at all, and whether they may start their own organization. Every new user receives the realm's default role for new users, including users arriving through an identity provider, and a provider's claim mappings can assign it per user.

Role	Grants
REALM_MEMBER	Sign in, and create and manage organizations, within the realm's self-service limits
REALM_USER	Sign in and use what they are invited to; cannot create organizations

REALM_USER is the right default when you create organizations and projects for your customers yourself. See Realms.

Organization

An organization role decides who manages the organization, its projects and its billing. Permissions are keys of the form <area>:<action> across three areas — organization, project and billing_profile.

Role	Grants
OWNER	Everything in the organization, including deleting it
ADMIN	Members, roles, groups, all projects and all billing
MEMBER	Read the organization and its billing, create projects, work with cloud resources

Custom roles can be defined per organization from the same catalogue, which is how narrower jobs are expressed — for example a finance role that reads invoices and payment history and nothing else, or a role that grants project:cloud_resource:read so its holders can see resources without being able to issue API credentials for them.

Membership can also be granted from the claims your identity provider issues, so that team membership in your directory decides project access. See Project access from identity claims.

Project

Within a project there are two roles.

Role	May
Owner	Everything a member may, plus rename the project, invite and remove members, and delete it
Member	Create, use and delete cloud resources in the project, and issue credentials for it

Organization owners and administrators are project owners on the organization's projects. Everyone else is a member unless made an owner explicitly.

Project membership in OpenStack

This is where the portal stops and the cloud starts. When a user becomes a member of a project, OSIE grants their Keystone identity a fixed set of roles on the corresponding Keystone project — the OpenStack Project Roles configured on that cloud provider's Provisioning tab, see Add a new OpenStack cloud. When none are configured, member, load-balancer_member, heat_stack_user and project_admin are used.

When those roles are granted and revoked is shown in Adding and removing a member. Three consequences follow, and they are the answer to what a user can do from the OpenStack CLI:

• Owner and Member apply to the project itself — renaming it, inviting people, deleting it. On the Keystone project both receive the same roles, so their privileges over servers, volumes and networks are identical, in the portal and from the CLI alike.
• The role set is per cloud. Changing it changes what every member of every project on that cloud can do. It is applied when a member is added and topped up when they sign in, so an added role reaches existing members on their next sign-in.
• Finer distinctions belong in OpenStack. To give one person different privileges on a project from another, assign roles to them in Keystone directly. OSIE leaves assignments it did not make alone — see Identity and access model.

Roles are withdrawn the same way they are granted: removing a member, or removing the claim that put them in a group, revokes the assignments on the Keystone project immediately.

Machine identities

Three kinds of credential exist alongside personal sign-in. Each is scoped, and none can exceed the access of whoever issued it.

Credential	Authenticates against	Scope
API secret	The OSIE admin API	The permissions ticked when it was issued
Application credential	Keystone, and the OpenStack APIs	The issuing user, in one project on one cloud
API user	Keystone, and the OpenStack APIs	A second Keystone user in the project, holding the project's roles

API secrets are covered in API authentication; the other two are issued by users themselves and are described in Access the cloud APIs.