docs-cloudfoundry-concepts/roles.html.md.erb at master · cloudfoundry/docs-cloudfoundry-concepts · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
---
title: Orgs, spaces, roles, and permissions in Cloud Foundry
owners: CAPI, Identity
---

This topic tells you about orgs and spaces in <%= vars.app_runtime_first %> foundations. It also describes the default permissions for user roles in <%= vars.app_runtime_abbr %>.

<%= vars.app_runtime_abbr %> uses a role-based access control (RBAC) system to grant appropriate permissions to <%= vars.app_runtime_abbr %> users.

Admins, Org Managers, and Space Managers can assign user roles using the Cloud Foundry Command Line Interface (cf CLI). For more information, see [Managing roles](./managing-roles.html).


## <a id='orgs'></a> 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, which have roles such as Org Manager, Org Auditor, and Org Billing Manager. Collaborators in an org share a resource quota plan, apps, services availability, and custom domains.

An admin can suspend an org 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.

<p class="note">
<span class="note__title"><strong>Note</strong></span>
In the v3 Cloud Controller API, this state is exposed as a boolean <code>suspended</code> field on the org. In the v2 Cloud Controller API, it was formerly known as the <code>status</code> field.
</p>

For more information about the actions that each role can perform, see [User Roles](#roles) and [User Role Permissions](#permissions).

For details on what activities are allowed for suspended orgs, see [Roles and Permissions for Suspended Orgs](#suspendedroles).


## <a id='spaces'></a> Spaces

A space provides users with access to a shared location for app development, deployment, and maintenance. An org can contain multiple spaces. Every app, service, and route is scoped to a space. Roles provide access control for these resources and each space role applies only to a particular space.

An admin or an Org Manager can suspend a space. When a space is suspended, only admins and Org Managers of the parent org can operate on the space. Other space roles cannot perform actions in the space until it is reactivated.

The Org Manager role administers the org but does not by itself grant permission to push apps, bind services, or otherwise modify the contents of a space. To perform these actions in a suspended space, a user must hold the Org Manager role and an appropriate space role, such as Space Manager or Space Developer.

<p class="note">
<span class="note__title"><strong>Note</strong></span>
The v3 Cloud Controller API exposes this state as a boolean <code>suspended</code> field on the space. The v2 Cloud Controller API does not expose space suspension.
</p>

For details on what activities are allowed for suspended spaces, see [Roles and Permissions for Suspended Spaces](#suspendedspaceroles).

Org Managers can set quotas on the following for a space:

* Usage of paid services
* Number of app instances
* Number of service keys
* Number of routes
* Number of reserved route ports
* Memory used across the space
* Memory used by a single app instance
* Log volume per second used across the space


## <a id='roles'></a> User roles

A user account represents an individual person within the context of a <%= vars.app_runtime_abbr %> 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](./architecture/uaa.html#scopes) in _User Account and Authentication (UAA) Server_.

### <a id='clients'></a> UAA clients

In addition to human users, <%= vars.app_runtime_abbr %> supports non-human principals called UAA clients. UAA clients authenticate using the `client_credentials` grant type and are intended for automation, CI/CD pipelines, and platform tooling that need to interact with the Cloud Controller API without a user session.

Like users, UAA clients can be assigned org and space roles. The UAA client ID takes the place of the username when managing client roles with the cf CLI. For more information, see [Assign roles to UAA clients](./managing-roles.html#clients).

The following describes each type of user role in <%= vars.app_runtime_abbr %>:

<%= vars.admin_role %>
<%= vars.admin_read_only_role %>
<%= vars.global_auditor_role %>

* **Org Managers**: Administer the org.

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

<%= vars.billing_manager_role %>
<%= vars.billing_manager_role_note %>

* **Org Users**: Read-only access to the list of other org users and their roles. In the v2 Cloud Controller API, when an Org Manager gives a person an Org or Space role, that person automatically receives Org User status in that org. This is no longer the case in the V3 Cloud Controller API.

* **Space Managers**: Manage a space within an org.

* **Space Developers**: Manage apps, services, and space-scoped service brokers in a space.

* **Space Auditors**: Read only access to a space.

* **Space Supporters**: Troubleshoot and debug apps and service bindings in a space.

<p class="note">
<span class="note__title"><strong>Note</strong></span>
The Space Supporter role is only available for the Cloud Controller V3 API. If a user with this role tries
to access a V2 endpoint, the API returns a 403.
</p>

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 or UAA client, you must first assign them an org role in the parent org. The error message `Server error, error code: 1002, message: cannot set space role because user is not part of the org` occurs if you try to assign a space role first.


## <a id='permissions'></a> User role permissions

Each user role includes different permissions in a <%= vars.app_runtime_abbr %> foundation. The following sections describe the permissions associated with each user role in active orgs, suspended orgs, and suspended spaces in <%= vars.app_runtime_abbr %>.

### <a id='activeroles'></a> Roles and permissions for active orgs

The following table describes the default permissions for various <%= vars.app_runtime_abbr %> roles in active orgs.

You can use feature flags to edit some of the default permissions in the following table.
For more information, see <a href="../adminguide/listing-feature-flags.html">Using Feature Flags</a>.


<%= partial 'oss_roles_table' %>


### <a id='suspendedroles'></a> Roles and permissions for suspended orgs

The following table describes roles and permissions applied after an admin suspends an org.

<%= partial 'suspended_org_roles_table' %>


### <a id='suspendedspaceroles'></a> Roles and permissions for suspended spaces

The following table describes roles and permissions applied after an admin or Org Manager suspends a space.

<%= partial 'suspended_space_roles_table' %>