You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on #579, @paulfitz@hexaltation@jonathanperret and I sat down to outline a solution to the more granular API keys feature request. Here is what we discussed :
Describe the solution you would like
We offer to introduce the concept of "Service accounts", partly inspired by what GCP is doing
At a high level, a service account is just like a regular user in Grist -- it can be added to any number of documents, workspaces, or orgs. ACL apply to this user and it has its own API key.
Service account lifecycle
Lyfecycle of a Service account follows the same rules as that of a user
The owner of a document can CRUD a Service account and add it to that document (note : technically, the user then becomes a "Guest" in the document's org/team site)
The owner of a workspace can CRUD a Service account at the workspace level
The owner of a team site can CRUD a Service account at the team site level
other roles (EDITOR or VIEWER) cannot CRUD a service account
There should be an admin panel at the team site level where all service accounts in the org can be listed (along with the documents they have access to) and managed centrally by team site owners
The Service account's API Key can only be accessed by the creator of the Service account (important : Owners of the team site should not be able to get the API key of Service accounts via the admin panel)
UI/UX considerations
The creation panel for a Service account could be a separate panel in the "Manage users" menu
There should be a way to describe what the service account will be used for (e.g. "Connect Grist to Mattermost", "Integrate with our marketing ETL pipeline", ...)
The UI should make clear that Service account are robots
The UI should show who created the service account in the first place
The new Service account admin panel should make it easy to provision, audit and delete Service accounts
(maybe) There should be a UI to re-generate a Service account API key (or maybe deleting the Service account and creating a new one would be enough ?)
Technical considerations
Service account key is shown at creation time only. If you need to read it again, you should regenerate it.
There should be a boolean column in the users table to differentiate Service accounts from regular accounts
Question about regenerating keys. Firstly, creating a new service account + deleting old is not equivalent to regenerating, because the existing account could have been manually added to certain documents, or mentioned in certain access rules.
If we support regenerating the secret key and associating it with the existing service account, should we support a grace period when both keys work? For example, Stripe offers this option. Stripe calls it "Rolling API Key", it's documented here: https://docs.stripe.com/keys#rolling-keys. At the time of regenerating a new key, you get to specify expiration for the previous one, which could be "Now" or after a certain time.
Asking this now, because if we need to support two secret keys for the same service account, this may affect the schema.
Describe the problem to be solved
Following up on #579, @paulfitz @hexaltation @jonathanperret and I sat down to outline a solution to the more granular API keys feature request. Here is what we discussed :
Describe the solution you would like
We offer to introduce the concept of "Service accounts", partly inspired by what GCP is doing
At a high level, a service account is just like a regular user in Grist -- it can be added to any number of documents, workspaces, or orgs. ACL apply to this user and it has its own API key.
Service account lifecycle
UI/UX considerations
Technical considerations
sa-{team-site}-{uuid}@getgrist.com
Here are the concrete next steps we agreed on :
The text was updated successfully, but these errors were encountered: