Skip to content

Multitenancy

EngFlow clusters support multitenancy: the ability for more than one organization to store data and execute actions on a cluster, isolated from other organizations.

This page explains how multitenancy works on EngFlow.

See also:

What is a tenant?

A tenant (also known as an instance) is a namespace for resources within an EngFlow cluster. Users can execute actions and read or write cache files in a specific tenant. Resources created in a tenant are isolated from other tenants.

As a concrete example, you can configure Bazel to use the tenant neuroflux using the flags below. Both flags are required.

--remote_instance_name=neuroflux
--bes_instance_name=neuroflux

These flags cause Bazel to set the instance_name field in the remote execution and build event service protocols, respectively. EngFlow interprets this as a tenant name. Action cache entries and content addressable storage files uploaded to the neuroflux tenant are not available on other tenants.

Managing access to tenants

EngFlow manages access to tenants through two APIs.

The IAM API is a gRPC API that cluster administrators (with the global-admin built-in role) can use to define and manage roles. A role is a set of resources and a set of actions that can be performed on them. Typically, an administrator creates one or more roles per tenant, granting varying levels of access to that tenant.

Roles are assigned to users via the OpenID Connect (OIDC) API. Cluster administrators decide which roles each user should have, then assign roles by setting the engflow_roles custom claim to a list of role names.

See Roles, Policies, and Permissions for more information.

Current limitations

EngFlow's support for multitenancy is still under active development, though several customers are using it in production. Our current implementation has some limitations that we plan to fix soon.

  • The Resource Usage API provides limited support for collecting usage data on each tenant. We plan to provide a simpler, more convenient API in the future.
  • Worker instances are currently shared across tenants. We plan to implement a permissioning system so that workers can be limited to executing actions on specific tenants.

We have several more features planned. Please contact support for more information.