Understanding Pivotal Cloud Foundry User Types
Page last updated:
This topic describes the types of users in a Pivotal Cloud Foundry (PCF) deployment, their roles and permissions, and who creates and manages their user accounts.
The users who run a PCF deployment and have admin privileges are operators. With Elastic Runtime installed to host apps, you add two more user types: Elastic Runtime users who develop the apps and manage the development environment, and end users who just run the apps.
PCF distinguishes between these three user types and multiple user roles that exist within a single user type. Roles are assigned categories that more specifically define functions that a user can perform. A user may serve in more than one role at the same time.
Operators have the highest, admin-level permissions. We also refer to operators as Ops Manager admins and Elastic Runtime admins because they perform an admin role within these contexts.
Operators fulfill system administrator roles covering the entire PCF deployment. They work primarily with their IaaS and Ops Manager, to configure and maintain Elastic Runtime component VMs. The component VMs, in turn, support the VMs that host applications. Typical operator tasks include:
- Deploying and configuring Ops Manager, Elastic Runtime, and other product and service tiles.
- Maintaining and upgrading PCF deployments.
- Creating user accounts for Elastic Runtime users and the orgs that Elastic Runtime users work within.
- Creating service plans that define the access granted to end users.
When Ops Manager starts up for the first time, the operator specifies one of the following authentication systems for operator user accounts:
- Internal authentication, using a new UAA database that Ops Manager creates.
- External authentication, through an existing identity provider accessed via SAML protocol.
The operator can then use the UAAC to create more operator accounts.
Elastic Runtime users are app developers, managers, and auditors who work within orgs and spaces, the virtual compartments within a deployment where Elastic Runtime users can run apps and locally manage their roles and permissions.
A Role-Based Access Control (RBAC) system defines and maintains the different Elastic Runtime user roles:
- Org Manager, Org Auditor, Org Billing Manager
- Space Manager, Space Developer, Space Auditor
The Orgs, Roles, Spaces, Permissions topic describes the Elastic Runtime user roles, and what actions they can take within the orgs and spaces they belong to. Some of these permissions depend on the values of environment variables.
Space Developer users work with their software development tools and the apps deployed on host VMs.
All Elastic Runtime users use system tools such as the cf CLI, PCF Metrics, and Apps Manager, a dashboard for managing Elastic Runtime users, orgs, spaces, and apps.
When an operator configures Elastic Runtime for the first time, they specify one of the following authentication systems for Elastic Runtime user accounts:
- Internal authentication, using a new UAA database created for Elastic Runtime. This system-wide UAA differs from the Ops Manager internal UAA, which only stores Ops Manager Admin accounts.
- External authentication, through an existing identity provider accessed via SAML or LDAP protocol.
In either case, Elastic Runtime user role settings are saved internally in the Cloud Controller Database, separate from the internal or external user store.
Org and Space Managers then use Apps Manager to invite and manage additional Elastic Runtime users within their orgs and spaces. Elastic Runtime users with proper permissions can also use the cf CLI to assign user roles.
Operators can log into Apps Manager by using the UAA Administrator User credentials under the Credentials tab of the Elastic Runtime tile. These UAA Admin credentials grant them the role of Org Manager within all orgs in the deployment. The UAA Admin can also use the UAAC to create new user accounts and the cf CLI to assign user roles.
End users are the people who log into and use the apps hosted on Elastic Runtime. They do not interact directly with Elastic Runtime components or interfaces. Any interactions or roles they perform within the apps are defined by the apps themselves, not Elastic Runtime.
App developers can configure apps any way they want to grant end user access individually. In a deployment with Single Sign-On Service for Pivotal Cloud Foundry installed, they can also offer end users a single login that accesses multiple apps.
The Single Sign-On (SSO) service can save user account information in an external database accessed via SAML or LDAP, or in the internal Elastic Runtime user store, along with Elastic Runtime User accounts.
To make the SSO service available to developers, an operator creates service plans that give login access to specific groups of end users. A Space Manager then creates a local instance of the service plan, and registers apps with it. Apps registered to the plan instance then become available via SSO to all end users covered by the plan.
The following table summarizes PCF user types, their roles, the tools they use, the System of Record (SOR) that stores their accounts, and what accounts they can provision.
|User Type||Available Roles||Tools They Use||Account SOR||Accounts They Can Provision|
|Operators||Admin (UAA Admin, SSO Plan Admin, other system admins)||
Ops Manager user store via UAA
External store via SAML
|Operators and Elastic Runtime Users|
|Elastic Runtime Users||
||Elastic Runtime user store via UAA
External store via SAML or LDAP
|Elastic Runtime Users within permitted orgs and spaces, and
|End Users||Defined by apps they use||Hosted apps||Individual apps
Elastic Runtime user store via SSO