User Access Management

Tenant Type

When a user signs up with F5® Distributed Cloud Services for the first time on F5® Distributed Cloud Console, it becomes an individual user tenant of our multi-tenant SaaS. Sign-up requires user to use email address as their user-id. First user of a tenant have the admin rights. (First user can give these rights to another user based role assignment, discussed further)

There two 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 tenant in F5 Distributed Cloud SaaS.
Enterprise tenants - this type of tenant can have multiple users. Each user within an enterprise tenant needs to have unique user-id. Enterprise tenants can have a unique name that is used as part of domain name to access Console or API. e.g “acme” enterprise will get “acme.ves.volterra.io” domain to access Console and 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 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 ves-io tenant.

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

Click here for sign-up information.

Single sign on

For Enterprise tenants, it is possible to configure Console login thru OIDC-compliant (OpenID Connect https://openid.net/connect/) Identity providers such as Google, Microsoft, Okta, Ping Identity, Github etc. 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 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 other) is restricted by using namespace scope. User configured access to 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 user for given namespace. E.g. user1 can configure objects in “test” namespace, however it can only read objects from “production” namespace. In other words a user who is admin for given namespace need NOT be admin for all namespaces.

Individual user and first user of enterprise tenant get an admin role. Admin role is special role that has permission to do anything in any namespace within the confines of tenant isolation and subscription plan.

Access Policy and Roles

Access control policy reuses 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 service 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, virtual-host-reader role can be created to give any user with this role to access 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 namespace and the default-role should be no access. Users should be assigned roles per namespace and this can be achieved by configuring user to namespace and role assignment as specified below:

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

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

Function of (tenant, user, namespace) → role
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. Following are some of the default roles that exists, it 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>), . . . }

Following API categories exist:

Category	Description
UAM	User access management, roles
Infrastructure	User access management, roles
Proxy	Virtual-host, advertise policy, endpoint etc
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 related 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, authorization flow will be the following:

Function of (tenant, user, namespace) → role
Function of (API, method) → {category1, category2, … }
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 policy, however, custom categories cannot be created at this time.

Credentials

Default credentials for users to web portal (or to obtain credentials for APIs) is to use their username and password. There are two ways for users can be authenticated using password:

Username and password is maintained in the F5 Distributed Cloud's user-management database - Even though the password is stored by the system, it is always stored using an irreversible hash for security reasons and none of the system software components or operators have access to this password. The password is never stored in the cleartext.
Single-sign On using OIDC and primary enterprise password store is elsewhere - OIDC can be used to sign-on using Google or Azure username/password store. User will be sent to OIDC provider for authentication.

Username password can only be used to access the web-portal - Console. In order to access the APIs, the user can use one of the following two methods:

Once the portal authenticates a user, it gives a short lived (for example, 1-hrs) cookie that is protected cryptographically. This short lived cookie can be used to access APIs for duration the cookie is valid. Web browser can automatically renew this cookie when users are active within 1 hour. There is 24-hrs session timeout that requires users to authenticate again.
Users can also download X.509 certificates from the Console - these certificates are valid for 14 days and can be used to access API using mTLS. If these certificates are added to system key store on 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 API(s) and kubectl for given virtual k8s instance. Optionally same certificate can be downloaded in form of kubeconfig file for given virtual k8s.
Users can also download a long-lived API token (it works the same way as cookie described above, except for longer expiry time) - This API token can be used by any software that wants to access F5 Distributed Cloud Services API. Long-lived API tokens to access API is a security risk. It is recommended that the customers mint their API tokens only in exceptional circumstances and 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 this quota is decided by their subscription plan. 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 20 virtual host objects. Currently all limits are per tenant and there are no limits per namespace.

Quota’s are only checked at the time of creation. System will check if current usage is equal or greater than limit, then creation will fail. When quota changes, already existing objects are grandfathered in, especially if the Quota is being reduced.

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

Details on Quota is covered in the API Specification.