129
Scoped API Access
Mark Wylde
When creating an API token, allow fine grained scoped control.
An example use case is, when using LetsEncrypt to generate your certificates, you can perform a DNS challenge to authenticate control of the domain. This adds a TXT record to your domain, confirming you have access to that domain.
You currently need to give your "god-mode" API token to do this using DigitalOcean.
With scoped access, you could create an API token with "dns:modify" and that's all that API token would be allowed to do.
This would reduce the attack surface if the API token gets leaked from your droplet.
Activity Feed
Sort by
Ayush Sharma
This is not even under review by the DO team, what a shame! Scoped API access is a must for CI/CD workloads and other tiny tasks these days. I will not like to put a “god-mode” token in every repo.
First option:
You guys already have read and write scopes in place, granulating it further should not be much of an hassle.
Second Option:
Do it the Github way, they recently added fine grained personal access tokens which made it easier for users to switch to these new tokens while also keeping backwards compatibility with old issued tokens.
Rather than the DO team adding “over the top” simple changes, they should really focus on Security for a while. Other platforms already have done this, it’s just the past good experience with DO which is making me stick for so long.
Things are so interlocking these days, the time might run out when there is a serious thing which needs to be deployed, at that point I’ll start to prefer other platforms with better security if this API access scopes are not added.
John Mulhausen
Merged in a post:
support granular OAuth2 scopes
Jackson
Currently the OAuth2 API only supports the very coarse scopes of "read" or "read write". It'd be great if we could request much more granular scopes. Really, any more granularity would be appreciated.
In the ideal, there'd be a way to request OAuth2 permissions for a very specific set of actions, and the authorizing user can see the price upfront before accepting. Ex:
<Application> is requesting permission to
* Read account SSH keys
* Read droplet information
* Create a 100gb data Volume in SFO2
* Create a 1gb Droplet in SFO2
Total cost: $20/month.
Currently, if you're using the API to create your own one-click applications, you need to educate the user about what you'll do with the full read/write access API token & the cost of the API actions you'll take. That can be pretty tricky. DO should be the source of truth on pricing.
John Mulhausen
Merged in a post:
Fine grained API tokens
Zowie
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 :-)
Mythic
The lack of scoped API access has had me move towards other platforms. Most recently just today decided to use another service instead of DigitalOcean due to the lack of scoped API tokens.
c
colajo
It's amazing to me - the inherent dysfunction that must be within the DO organisation for this to still not be implemented. At this point, after years of waiting, I'm not even mad anymore. Kinda just in awe.
c
colajo
Jeff Braunstein Is this just not something that DO is interested in, for some reason?
Joost Schuttelaar
Have the exact same use case as Mark Wylde (LetsEncrypt DNS challenge) and was surprised that I couldn't limit the API key scope to domains.dns read/write only. I'd be fine to edit this in a YAML file or something versus a fancy webinterface, but sticking this key on a box somewhere allowing access to dozens of droplets feels unsafe.
Daniel
The lack of this feature makes the API unusable.
P
Poulp
+1 for this one. Having control over CRUD (and not only read/write) + settings for each api endpoint would be great.
M
Martin H.
This is the only (blatantly) missing feature which makes me think again and again if we should leave this platform.
It does not make sense to offer features for medium-sized companies such as Kubernetes clusters while opening the doors wide for abuse with a single unrestricted token which has to be used in different places.
Adding new features and resources to the control panel & API all the time makes the attack surface grow even more. I am waiting for the first company's infrastructure to get hit really hard because of this dangerous limitation.
I get that DigitalOcean's initial target audience were single developers or small companies, but now I think that's no longer necessarily the case. You should really think about changing this, if you do not want to lose SMEs to the big cloud competitors.
(Btw, I built a proxy as workaround. It is far from complete though: https://github.com/djmaze/do-api-proxy)
(Forgot to add: It should also be possible to limit spaces access keys to individual spaces, but that's a different feature I admit.)
t
thomsley
Similar use case, I'm running
external-dns
on DOKS cluster, and it could totally spin up a bunch of droplets if it wanted to. Being able to scope to DO API endpoints+verbs would get us a huge step closer to least privilege accessLoad More
→