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.

There are two types of tenants allowed in the system:

1. 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.

2. 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

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.

Access Policy and Roles

The access control policy reuses the service policy. F5 Distributed Cloud Services API is the service being protected, and API users are the clients. The access policy, along with roles, provide a mechanism to classify clients and protect API services using the actions set in the access control policy.

So instead of having a list of clients, a group of clients can be considered a role. So access policies can be written in terms of roles instead of individual clients. For example, a virtual-host-reader role can be created to give any user with this role access to the GET and LIST APIs for the virtual-host object in the system.

In an enterprise environment, it may be desirable for a user to have different roles in different namespaces. The default role should be no access. Users should be assigned roles per namespace, and this can be achieved by configuring a user to a namespace and a role assignment as specified below:

{user1} → {“namespace1”} → {“role1”} {“namespace2”} → {“role2“} {“*”} → {“default-role”}

When an API or object is accessed, the authorization flow will be the following:

1. Function of (tenant, user, namespace) → role
2. Function of (role, API, method, access-policy) → {allow or deny}

For convenience, F5 Distributed Cloud Services provide built-in/default roles and policies for these roles to get you started. The following are default roles that exist (may not be an exhaustive list):

• Default role: No access to any APIs or Objects
• Admin: All access
• Network admin: Access to only Networking APIs
• Monitor: Access to all Read APIs

User type	Namespace	Role	Description
New User	* (All)	Default-role	All new users have no access
First User	* (All)	Admin	First user has all the access
Overall admin	* (All)	Admin	This user will have all access
Namespace admin	<given-namespace>	Admin	This user will have all access for <given-namespace>

Similar to how a role can be used as an indirection for {client, namespace}, a role can also be used as an indirection for API access controls. A group of APIs and its methods are called an API category. For example:

API-category-reader = { (GET, <path of API-1 >), (GET, <path of API-2> ), . . . }

The following API categories exist:

Category	Description
UAM	User access management, roles
Infrastructure	User access management, roles
Proxy	Virtual-host, advertise policy, endpoint, and more
General	Miscellaneous
Proxy Monitor	Monitoring data for proxy
Network	Virtual network related
Internal	Currently available only for F5 Distributed Cloud operators
Proxy security	Service Policy
Infra-monitor	Monitoring data for system namespace
Labels	Known label management
Secrets	Secrets management
Monitor	General data collection access
IaaS-CaaS	Application Management and Virtual K8s
Virtual_sites	Virtual Sites API
Proxy WAF	WAF for proxy

Each of the categories above will have a reader and a writer built-in role.

When an API is accessed, the authorization flow is the following:

1. Function of (tenant, user, namespace) → role
2. Function of (API, method) → {category1, category2, … }
3. Function of (role, categories, access-policy) → {allow or deny}

With existing built-in/default roles and corresponding access policy, most tenants will not need anything else. That said, the tenant administrator can create custom roles and access policies. However, custom categories cannot be created at this time.

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.

---