The cloud agent server defines a highly scalable runtime for lambda-like agent execution. Cloud agent servers include an attached persistent disk, but the only server functionality is invoking agents; there is no HTTP DB API, no persistent sessions, etc. The idea is to provide a useful cloud-based execution environment that can appropriately scale for free-tier users. In terms of functionality, the agent server is a drop-in replacement for the Studio Server for apps that only contain agents. It does not serve as a Mix runtime for interacting with screens, etc., or provide any way to interact with the underlying databases other than via agents.
The agents invoked are the same agents as used elsewhere in the platform, so you can invoke them locally as well as deploy them to the cloud agent server.
The cloud agent environment is divided into “workspaces” which represent both a database namespace and a single point of metering; conceptually these are similar to existing cloud server workspaces like remix-beta.remixlabs.com, etc. Workspaces are specified within the URLs for a given cloud agent server, eg, in https://agt.remixlabs.com/v1/ws/demo, the workspace is demo.
We distinguish between "owner" and "admin" roles for both workspaces and db's. Ownership is immutable, and is connected to billing and metering. "A user in tier X can have Y deployed apps" is a statement about app owners, not admins. Any given resource has exactly one owner, which is the user that created it. On creation, the owner can make themselves admin, or assign this to another user. Admins can grant further permissions, including making more admins, but they cannot change the ownership.
Access control for the workspace itself is managed in the admin app as for individual users, but ownership is outside this scheme so as to more easily ensure immutability. The owner of the workspace, and the owner of each db, are stored outside of the db's themselves.
Users are authenticated by a central auth server (auth.remixlabs.com), and one user can be associated as a user or owner of an arbitrary number of workspaces. If allowed by the app owner, agents can be invoked anonymously (eg, for use in app clips that are used by non-signed-in users).
Access control works similarly to IAM/RBAC systems like GCP's. We define grants as a triple of subject, role, and resource. Subjects can be specific users, domains, agents, or user categories like all-users (any signed-in user) or anonymous (no restrictions). (A domain is the host part of a user’s email address, like remixlabs.com.) Roles, like editor or admin, group together a few concrete permissions. The schema is:
{
subject: STRING=(user/USER_NAME | domain/HOST | agent/SERVER:WORKSPACE/DB_NAME/AGENT_NAME | all-users | anonymous),
role: STRING=(runner | editor | admin | db/creator),
resource: STRING=(agent/DB_NAME/AGENT_NAME | db/DB_NAME | workspace)
}
Checking permission involves testing an actor/action/resource triple, noting that all three parts might have both specific and more general matches. (A user might belong to one or more groups, an action might be permittxed by multiple roles, and a resource might be covered by parent or meta resources.)
The agent server currently recognizes the following roles, the corresponding permissions, and the resources they can apply to:
| role | permissions | resources |
|---|---|---|
| runner | run | agent/DB_NAME/AGENT_NAME, db/DB_NAME, workspace |
| editor | run, export, read, write | db/DB_NAME, workspace |
| admin | run, export, read, write, grant_permissions, delete, create_db | db/DB_NAME, workspace |
| db/creator | create_db | workspace |
Installing a .remix file involves a number of separate operations, and its access check is currently implemented as requiring the admin role on the workspace.
Note that db/creator does not imply you can replace (or even read) an existing db, only create one where one doesn't exist. Having "run" permission for a workspace implies all databases in it, and for a database implies all agents in it.