Access
Let people and workloads read or change a Project's data by giving them roles with grants.
To let someone read or change a Project's data, you give them a role on that
Project. For example, to let the nightly-curation pipeline write to the
demo Project, you grant its workload the editor role:
spiral projects grant "$SPIRAL_PROJECT" --role editor --workload-id "$WORKLOAD_ID"The grant takes effect on the pipeline's next control-plane request. Revocation prevents new storage access at the next permission check. Existing storage credentials and signed requests can remain valid until they expire. See Security.
Roles
A role is a set of permissions on one Project:
| Role | Use it for |
|---|---|
viewer | Reading resources and history |
editor | Reading and writing resources |
admin | Everything editor can do, plus managing grants and the Project |
Organization roles (owner, member and guest) are a separate thing. They
control account actions, such as creating Projects and inviting people. Being
a member of an Organization does not by itself give access to any Project's
data; only a grant does.
Who can receive a grant
A grant gives one role on one Project to a principal, the identity that sends requests. A principal is one of:
- one person in the Organization, a user, who signs in through a browser or the CLI;
- every user with a given Organization role, for example every
member; - one workload, a pipeline or service with its own credentials and no personal sign-in.
Grants and audit records refer to the principal, not to the credential it used. That way you can rotate a pipeline's key without granting it access again, and the audit log still shows which pipeline acted.
A new Project starts with a few grants, such as admin for its creator.
Authorization lists them and shows how to
change them.
Applications that act for a user
A third-party Application can act for a user
with a delegated token. The token carries scopes, such as tables:read,
which the user approved. A request succeeds only when the user has the
permission and one of the scopes covers it, so a scope can narrow what an
Application does but never adds a permission the user lacks.
Related pages
- Authorization manages grants and checks permissions.
- Authentication signs in users and workloads.
- Permissions lists each permission, the roles that hold it, and its scope.