User Access Management

Tenant Type

When a user signs up with Volterra for the first time on Volterra 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:

  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 tenant in volterra SaaS.

  2. 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 Volterra Console or API. e.g “acme” enterprise will get “acme.ves.volterra.io” domain to access Volterra 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 volterra system. Any tenant can access ves-io/shared namespace and sites owned by ves-io tenant. All volterra 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 sing-up information.

Single sign on

For Enterprise tenants, it is possible to configure Volterra 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 Volterra Console. We require that the Identity provider support authorization code flow of OIDC. This setup allows Enterprise customers to use Volterra 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.

  • Volterra APIs - As described above, access to volterra 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. Volterra APIs is service being protected, API users are the clients, and Roles are indirection to classify clients.

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:

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

For convenience volterra provides 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 \ Admin This user will have all access for \

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, ), (GET, ), . . . }

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 volterra 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:

  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 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 volterra user-management database - Even though the password is stored by Volterra, it is always stored using an irreversible hash for security reasons and none of the volterra 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 - Volterra Console. In order to access the APIs, the user can use one of the following two methods:

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

  2. Users can also download X.509 certificates from the Volterra 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.

  3. 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 volterra 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.