Table-scoped API tokens

[RaitoBezarius]

Describe the problem to be solved

When I write automation against Grist, I would like to avoid exposing all my databases and tables to the automation I'm deploying for security reasons.

Describe the solution you would like

I'd like Grist to provide table-scoped (better: advanced policy driven) API tokens such that an API token like that can only interfere with a specific table of a Grist database.

[fflorent]

Hi @RaitoBezarius!

Sounds like Service Accounts would fit well your need, wouldn't it?
https://support.getgrist.com/api/#tag/service-accounts

[RaitoBezarius]

@fflorent Super interesting, thanks. Do you know if there's a clear path to use a service account to scope its API key to a table in a Grist database? Perhaps the question should become: can we have API keys scoped to tables whether they go via a svc account or not.

[fflorent]

@RaitoBezarius Of course there is :)
When you create a service account, it is attributes a false email (in @serviceaccounts.invalid).

This way, you may:

• invite the service account to any document as you do for users
• create access rules for this service account to restrict its rights to whatever you want (grant or deny access to tables, rows, columns, etc.), just as you do for users too

For now, this feature lacks of discovery because there is no UI to create them, but it is very convenient otherwise in many aspects :)

[RaitoBezarius]

@fflorent If the service account is attributed to one false email, does this mean that you can have at most one service account that can be scoped? Can people create their own svc accounts on their own and provision stuff based on that, etc. ?

[RaitoBezarius]

Extension thoughts, I don't mind not having an UI, but maybe there should be a Terraform provider or something so that you can provision service accounts as code.

[fflorent]

@fflorent If the service account is attributed to one false email, does this mean that you can have at most one service account that can be scoped?

Sorry, this question is unclear to me (if I miss your point, could you be more concrete?).

Service accounts rights are independent to its owner rights, in other word the service account owner might have less rights on a document than their service account.

Just think of service accounts simply as "false users" (which they actually are technically speaking) that real users can create. The owner of the service account is given a false email address (of this form: <uuid>@serviceaccounts.invalid) and an api key for this service account. With this false email address, the service account can be invited to resources, i.e. team sites (aka organizations), workspaces and documents. They can also be granted partial access to documents through access rules.

Owners of service accounts can also regenerate their api keys, revoke them and also delete service accounts.

When an owner of a service account is disabled, their service account is disabled too.

Can people create their own svc accounts on their own and provision stuff based on that, etc. ?

Every "real" users can create as many service accounts as they want.

Extension thoughts, I don't mind not having an UI, but maybe there should be a Terraform provider or something so that you can provision service accounts as code.

I tend to think it is out of scope of this project, and maybe it could be provided by the community?
Given the fact that you can call the API to create service accounts, I guess any automation can be done (as long as you have a server running, that's maybe the inconvenience of your point?).