User Access Management

Tenant Type

When you sign up with F5® Distributed Cloud Services for the first time on F5® Distributed Cloud Console, your account becomes an individual-user tenant of F5's multi-tenant Distributed Cloud Services. Sign-up requires you to use an email address as your user ID. The first user of a tenant has the admin rights. The first user can give these rights to another user based on role assignment.

Following types of tenants allowed in the system:

• Individual tenants: This type of tenant can only have one exact user that has all the right credentials. Since there is only one user, access control does not make sense here. All individual users need a unique username and hence they are required to give a valid email address as their user ID. All individual users become unique individual tenants in F5 Distributed Cloud Services

• Enterprise tenants: This type of tenant can have multiple users. Each user within an enterprise tenant needs to have a unique user ID. Enterprise tenants can have a unique name that is used as part of a domain name to access Distributed Cloud Console or API. For example, the “acme” enterprise will get the acme.ves.volterra.io domain to access Console and the tenant ID will be “acme-abcdefgh” (\<tenant>-\<random-8-char>).

A tenant cannot access config objects or sites of another tenant. There is a special tenant called “ves-io” representing F5 Distributed Cloud Services system. Any tenant can access ves-io/shared namespace and sites owned by ves-io tenant. All F5 Distributed Cloud Regional Edge Sites are owned by the ves-io tenant.

Either during sign-up or when the admin adds a new user to a tenant, a verification email is sent to the new user. This email has a link to set up a new password. The password is stored as a salted hash, so no person or system ever knows the actual value of the user password. The email will be used to recover the password. Enterprise tenant admins can delete users. Individual users can delete their account. All data will be lost for a given tenant if that was the last user of a given tenant.

Click Getting Started with Console for sign-up information.

Single Sign On

For enterprise tenants, it is possible to configure Console login through OIDC-compliant (OpenID Connect https://openid.net/connect/) Identity providers, such as Google, Microsoft, Okta, Ping Identity, GitHub, and more. The setup requires creating credentials with the identity provider and provisioning them in the Console. We require that the Identity provider support authorization code flow of OIDC. This setup allows enterprise customers to use Distributed Cloud Console using their existing user authentication system.

Access Control

F5 Distributed Cloud (F5XC) uses a layered access control model composed of API Elements, API Groups, Roles, Namespaces, and Services. Access is evaluated per API Element, scoped to the user's namespace-level role assignment, and filtered through the tenant's service entitlements.

There are two types of access control that can be configured in the system:

• Individual configuration objects: Access to individual object instances by users and by objects instances themselves (by way of one object referring to another) is restricted by using a namespace scope. User-configured access to a given namespace can see objects in that namespace, tenant/shared, and ves-io/shared namespaces only. Objects in a given namespace can only refer to other objects in that namespace, tenant/shared, or ves-io/shared.

• F5 Distributed Cloud Services APIs: As described above, access to the API is also scoped by namespace.

Access control can be configured by assigning roles to users for a given namespace. For example, user1 can configure objects in a “test” namespace. However, it can only read objects from a “production” namespace. In other words, a user who is admin for a given namespace need not be admin for all namespaces.

The individual user and first user of an enterprise tenant gets an admin role. The admin role is a special role that has permission to perform anything in any namespace within the confines of tenant isolation and subscription plans.

API Elements

An API Element is the most granular unit of access control in F5XC. It represents a specific operation, defined as an API path and method pair. Every action performed on the platform: whether through UI, API, CLI, or IaC Automation (Terraform); maps to an API Element.

For example:

POST /config/namespaces/prod/origin_pools
GET /config/namespaces/dev/virtual_hosts

API Elements are never assigned to users or roles directly. Each API Element is associated with an API Group, which is associated to a Role, which can then be applied to a User.

API Groups

An API Group is a collection of related API Elements. It represents a consistent boundary for service operations. Roles are composed of API Groups, and grant access to Elements.

Each API Group is designed to reflect a logical service surface area. For example, one group may provide full CRUD access to virtual host resources, while another enables read-only access to monitoring APIs.

Every Element belongs to exactly one API Group. This one-to-one mapping between Element and Group ensures clarity in enforcement, simplifies audits, and reduces the risk of conflicting permissions.

When defining access policies, whether using built-in roles or custom Roles, API Groups are the building blocks used to control what users can and cannot do.

Services

Each API Group belongs to a Service. Services represent functional product areas that can be selectively enabled per tenant.

Plan Based Access Control (PBAC) enforces service enablement checks alongside role-based access permissions. Even if a user has the correct role scoped to the correct namespace, they cannot access an API Element if the Service that its API Group belong to is not enabled for the tenant.

For example:

• The API Group for Advanced Bot Protection belongs to the Bot Defense Advanced Service.
• If the Bot Defense Advanced Service is not enabled, access to the API Elements within that Service's API Groups will be blocked. The platform will return a 403 Forbidden response.

This separation ensures that access is governed not just by user identity and role assignment, but also by what the tenant is entitled to use.

Namespace-Scoped Permissions

All permissions in F5XC are scoped to Namespaces. A User must be explicitly assigned a role in a given namespace in order to perform any operations within it.

A User with a Role in a Namespace can:

• Interact with configuration objects in that namespace
• Reference shared objects in tenant/shared and ves-io/shared
• Call APIs whose Elements are included in their Role's API Groups and permitted within that namespace

Objects within a Namespace can only reference:

• Other objects in the same Namespace
• Objects in tenant/shared or ves-io/shared

Namespace scoping applies consistently across all resources and APIs. There is no implicit cross-namespace access unless explicitly configured.

Access Policies and Roles

A Role is a collection of API Groups. It defines which API Elements a user may invoke. Role assignments are made per User and per Namespace.

A typical User's Namespace to Role mapping might look like:

user → {
  "development-ns" → "f5xc-waap-admin",
  "staging-ns" → "f5xc-waap-user",
  "production-ns" → "f5xc-waap-monitor",
}

System-Defined Roles

F5XC provides a curated set of Roles aligned to common operator tasks and platform workspaces such as WAAP, App Connect, and MCN. These Roles are maintained by F5 and updated automatically as new API Elements and API Groups are introduced.

For example:

• f5xc-waap-admin
• f5xc-appconnect-user
• f5xc-mcn-monitor

These System-Defined Roles are the recommended default for most operational use cases. They align closely with UI workflows and are structured to reduce the complexity of managing permissions manually.

Custom Roles

Tenants can define their own Roles by selecting combinations of existing API Groups. Custom Roles allow for fine-grained access tailored to specific teams, workflows, or automation requirements. Custom Roles cannot define new API Groups and do not automatically update when the platform introduces new APIs. Role maintenance is the tenant's responsibility.

Tenant Owner Role

The Tenant Owner is a special System-Defined Role given to the first user created in a tenant. This role carries elevated privileges and tenant-wide administrative authority.

• The Tenant Owner is automatically assigned Admin permissions across all namespaces.
• The Tenant Owner can create, assign, and revoke roles for other users.
• The Tenant Owner can perform certain restricted operations, such as elevating other users to Tenant Owner or initiating tenant deletion.

While the Tenant Owner has full administrative scope, they are still subject to PBAC.

Credentials

The default credentials for users to access the web portal (or to obtain credentials for APIs) is to use their username and password. There are two ways for users to be authenticated using a password:

• Username and password is maintained in the F5 Distributed Cloud Services user management database. The system stores the password, but it is always stored using a hash that cannot be reversed. This is a security measure to keep the password safe. None of the system software parts or operators can see this password. The password is never stored in clear text.

• Single-sign on (SSO) using OIDC and primary enterprise password stores is elsewhere. OIDC can be used to sign-on using Google or Azure username and password stores. You will be sent to the OIDC provider for authentication.

The username and password can only be used to access the web portal, as in Distributed Cloud Console. To access the APIs, the user can use one of three methods:

1. Once the portal authenticates a user, it gives a short-lived (for example, one hour) cookie that is protected cryptographically. This short-lived cookie can be used to access APIs for the duration the cookie is valid. The web browser can automatically renew this cookie when users are active within one hour. There is a 24-hour session timeout that requires users to authenticate again.

2. Users can also download X.509 certificates from the Console. These certificates are valid for 14 days and can be used to access APIs using mTLS. If these certificates are added to system key stores on a local desktop/laptop, then applications, like the browser, can use it automatically. Similarly, a certificate can be downloaded that is also valid for all virtual k8s APIs and kubectl for a given virtual k8s instance. Optionally, the same certificate can be downloaded in the form of a kubeconfig file for a given virtual k8s.

3. Users can also download a long-lived API token (it works the same way as the cookie described above, except for a longer expiry time). Any software that wants to access F5 Distributed Cloud Services API can use this API token. Long-lived API tokens to access the API are a security risk. F5 recommends that customers mint their API tokens only in exceptional circumstances and that they be minted with special user accounts with minimal access to the system.

Quota

Every tenant has a quota for all configuration objects in the system, and their subscription plan decides this quota. For certain billing plans, quota can be increased by opening a support ticket or using self-service.

Quota is a list of {kind, limit} for all “kinds” of objects in the system. For example {virtual_host, 20} means the tenant can create only twenty (20) virtual host objects. Currently, all limits are per tenant and there are no limits per namespace.

Quotas are only checked at the time of creation. The system will check if current usage is equal or greater than the limit, and then the creation will fail. When a quota changes, existing objects are grandfathered in, especially if the quota is being reduced.

You can get the current quota and usage metrics using an API that reports a list for all “kinds” → list of {kind, Quota. Use}

Details on quotas are covered in the API Specification.