The cloud agent server defines a highly scalable runtime for lambda-like agent execution, as well as a set of associated databases. It can also serve as a web host for running the Remix Studio or web app runtimes.
The cloud agent environment is divided into “workspaces” which represent both a database namespace and a single point of metering. 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.
We also support “anonymous” and “all users” access to agents. Anonymous access means that agents can be invoked without an authentication token; “all users” access means any authenticated user can run the agent. You can grant anonymous access to agents by granting the runner role to the subject "anonymous" on an agent resource like "agent/some-db/some-agent":