Orgs, Spaces, Roles, and Permissions

This topic describes orgs and spaces in CF foundations. It also describes the default permissions for user roles in CF.

Overview

CF uses a role-based access control (RBAC) system to grant appropriate permissions to Swisscom Application Cloud users.

Admins, Org Managers, and Space Managers can assign user roles using the Cloud Foundry Command Line Interface (cf CLI). For more information, see Users and Roles in Getting Started with the cf CLI.

Orgs

An org is a development account that an individual or multiple collaborators can own and use. All collaborators access an org with user accounts. Collaborators in an org share a resource quota plan, applications, services availability, and custom domains.

By default, an org has the status of active. An admin can set the status of an org to suspended for various reasons such as failure to provide payment or misuse. When an org is suspended, users cannot perform certain activities within the org, such as push apps, modify spaces, or bind services. For details on what activities are allowed for suspended orgs, see Roles and Permissions for Suspended Orgs.

Spaces

Every application and service is scoped to a space. An org can contain multiple spaces. A space provides users with access to a shared location for application development, deployment, and maintenance. Each space role applies only to a particular space.

User Roles

A user account represents an individual person within the context of a CF foundation. A user can have one or more roles. These roles define the user’s permissions in orgs and spaces.

Roles can be assigned different scopes of User Account and Authentication (UAA) privileges. For more information about UAA scopes, see Scopes in Component: User Account and Authentication (UAA) Server.

The following describes each type of user role in CF:

  • Admin is a user role that has been assigned the cloud_controller.admin scope in UAA. An admin user has permissions on all orgs and spaces and can perform operational actions using the Cloud Controller API. To create an account with cloud_controller.admin scope for your installation, see the Create an Admin User topic.
  • Admin Read-Only is a user role that has been assigned the cloud_controller.admin_read_only scope in UAA. This role has read-only access to all Cloud Controller API resources.
  • Global Auditor is a user role that has been assigned the cloud_controller.global_auditor scope in UAA. This role has read-only access to all Cloud Controller API resources except for secrets such as environment variables. The Global Auditor role cannot access those values.
  • Org Managers: Administer the org.

  • Org Auditors: Read-only access to user information and org quota usage information.

  • Billing Account Owners manage [billing accounts](../billing/accounts.html.md.erb) and have access to invoices.

Note: The Billing Account Owner role is specific to the Swisscom Application Cloud and can therefore only be assigned through the web console.

  • Org Users: Read-only access to the list of other org users and their roles. When an Org Manager gives a person an Org or Space role, that person automatically receives Org User status in that org.

  • Space Managers: Administer a space within an org.

  • Space Developers: Manage applications and services in a space.

  • Space Auditors: Read-only access to a space.

For non-admin users, the cloud_controller.read scope is required to view resources, and the cloud_controller.write scope is required to create, update, and delete resources.

Before you assign a space role to a user, you must assign an org role to the user. The error message Server error, error code: 1002, message: cannot set space role because user is not part of the org occurs when you try to set a space role before setting an org role for the user.

User Role Permissions

Each user role includes different permissions in a CF foundation. The following sections describe the permissions associated with each user role in both active and suspended orgs in CF.

Roles and Permissions for Active Orgs

The following table describes the default permissions for various CF roles in active orgs.

Note: You can use feature flags to edit some of the default permissions in the following table. For more information, see Using Feature Flags.

Activity Admin Admin Read-Only Org Manager Org Auditor Org Billing Manager Space Manager Space Developer Space Auditor
Scope of operation Org Org Org Org Org Space Space Space
Assign user roles
View users and roles
Create and assign org quota plans
View org quota plans
Create orgs * * * * * *
View all orgs
View orgs where user is member
Edit, rename, and delete orgs
Suspend or activate an org
Create and assign space quota plans
Create spaces
View spaces
Edit spaces
Delete spaces
Rename spaces
View the status, number of instances, service bindings, and resource use of applications
Add private domains
Deploy, run, and manage applications
Instantiate and bind services to applications
Associate routes, instance counts, memory allocation, and disk limit of applications
Rename applications
### Roles and Permissions for Suspended Orgs The following table describes roles and permissions applied after an operator sets the status of an org to _suspended_.
User Role Admin Admin Read-Only Global Auditor Org Manager Org Auditor Org Billing Manager Org User Space Manager Space Developer Space Auditor
Scope of operation Org Org Org Org Org Org Org Space Space Space
Assign user roles Yes
View users and roles Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Create and assign org quota plans Yes
View org quota plans Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Create orgs Yes
View all orgs Yes Yes Yes
View orgs where user is a member Yes** Yes** Yes** Yes Yes Yes Yes Yes Yes Yes
Edit, rename, and delete orgs Yes
Suspend or activate an org Yes
Create and assign space quota plans Yes
Create spaces Yes
View spaces Yes Yes Yes Yes Yes Yes Yes
Edit spaces Yes
Delete spaces Yes
Rename spaces Yes
View the status, number of instances, service bindings, and resource use of apps Yes Yes Yes Yes Yes Yes Yes
Add private domains Yes
Deploy, run, and manage apps Yes
Instantiate and bind services to apps Yes
Associate routes, instance counts, memory allocation, and disk limit of apps Yes
Rename apps Yes
Create and manage Application Security Groups Yes

Unless disabled by feature flags.

**Admin, admin read-only, and global auditor roles do not need to be added as members of orgs or spaces to view resources.

View the source for this page in GitHub