Fine grained API tokens
The new API is great and being able to create multiple access tokens is too, but it feels extremely dangerous to save an API token that can potentially destroy ALL my droplets for all my clients on just a single droplet that only needs the API for a specific use case.
My example: a weekly task that consumes a large amount of memory: my client has to contact me to resize 4GB -> 32GB before initiating the task (or pay for a 32GB instance all the time, which doesn't make sense). It feels strange that I have to do all this, just because I'm refusing to do something that's dangerous.
Hope you'll be able to do something about it :-)
-
Zowie
- Sep 11 2018
-
More Granular control of api Merged
Currently the api key is either read or write. A more granular approach would be good which allows you to specify for each feature (snapshots/droplets/images/block storage etc) whether you have read/create/delete privilege. So for instance yo...0
-
API - Personal Access Tokens rights enhancements in stead of only full admin rights Merged
Currently there's no way to differentiate in rights for the Personal Access Tokens, if you create a write token, it basically is full admin access to the account. I'd like to have a possibility to limit the access to certain parts, specifically ...0
Related ideas
The easiest way to achieve this is to define a regex (or many regexes) at the same time you create the key.
If at least one regex is matched, the API proceeds with the requeset.
Then, it will depend on your abilities with regex to let that token do or not do certain tasks.
Easy and effective !!!!
Attachments Open full size
I want manage my DNS records via API, but I definitely don't want to use token what can modify droplets or my backups/snapshots for that :(
Attachments Open full size
limit API options for specific team members
Attachments Open full size
This is probably the most important enterprise feature, and while you wait, we (a third party) provide it to our clients via our Dashboard, mentioned here:
https://safeharbour.io/help/pages/working_with_organizations.html#managing-your-users
you can set what the person in the SafeHarbour org can do down to the resource (droplet only or images only, within these read only or read+write, quite detailed permissions, check it out)
see the demo:
https://safeharbour.io/help/pages/working_with_organizations.html#demo-on-our-fine-grained-permissions
Attachments Open full size
This is absolutely something I would like to see happen.
I would also like to request possibly a temporary token after a single session the token expires.
Attachments Open full size
Fine grained control would be nice, with filtering on hostname prefixes/suffixes or other tags.
For your use case, you could create a simple API endpoint for your customer and then utilize the DO API in your API to do the resize..
Attachments Open full size
It'd be nice to have API keys only allowed to create / operate / delete a subset of droplets only.
Currently providing the API keys to an app gives full control over all the existing droplets and is a risk.
Attachments Open full size
I'd like the tokens to be limited to DNS management records.
Ideally, there could be also even finer permissions that allow a token to add/delete/update A and TXT records which are used by let's encrypt
Attachments Open full size
Fine grained permissions is important for every public API, because you will inevitably be invoking it in less trusted contexts. I would wager that most administrators consider their droplets to be a generally less trusted context than the administration control panel. And the request handlers serving up http responses are less trusted still, that's why they run as limited users. To give an API key with the full powers of your project administrator to a lowly request handler completely undermines sane access control. Yet that must be what is happening on some systems. But it needn't be if only it were easy for users to do otherwise.
Permissions for each API method must be off by default, with it being up to the user to select which methods are needed. Also you must be able to restrict by project, etc..
Until a system is in place that makes it easy to use API keys responsibly, I will consider all API-related security breaches to be the fault of DO for not providing the minimum tools necessary. This goes for all public APIs, not just the management API.
Attachments Open full size