I’m looking to use the DO API to update Firewall entries from a web-application. The hope is to allow clients to access critical application services 24/7 without worrying about anything like DDoS from an external source (there is still an internal source risk, but being that this is a paid service, the risk is much lower and traceable/blockable).
It seems like there is still only read-only and read-write scopes on tokens. This seems like a blatant overlook from a security stance, especially considering there can be multiple projects on one account.
In addition, it would be nice to disallow my CI/CD from having access to my entire server infrastructure when it only needs image repo access. I’m thinking I might need to stop using DO repos altogether and get a Docker subscription or something because it’s just too risky. I like DO because it’s one of the cheaper options, but it’s just not practical. Maybe I can integrate directly with Gitlab? But then I’m limited to one repo and I produce several projects (and tagging wouldn’t make sense for them).
For the Firewall I’m also thinking I might be able to use Cloudflare with their API. Scoping wouldn’t be a problem because it’d be isolated to that platform.
So there are solutions, but all of this seems like it could just be easily resolved by allowing more granular scopes with API tokens.
Would love to hear your thoughts on this, thanks!
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hi there,
A quick update here, custom scopes for DigitalOcean API Tokens is now in beta!
This API token enhancement provides additional flexibility in protecting your cloud resources by letting you select only the necessary scopes.
Please fill out this form if you are interested in participating in the beta..
Custom scopes introduce more specific permissions, like creating Droplets or updating cloud firewalls. Using custom scopes lets you secure your workflows by granting only the permissions the token needs and restricting access to other resources and actions.
Generally, the CRUD scopes map to equivalent actions on the associated kind of resource:
Create scope lets you create the resource type and perform additive actions within that resource type. For example,
database:create
lets you create database clusters and create new users or databases within that cluster.Read scope lets you view information about a resource by type and also view information that the resource returns. For example,
app:read
lets you view App Platform apps and their logs.Update scope allows you modify a resource type and perform actions that would otherwise modify a resource. For example,
droplet:update
lets you power a Droplet on or off.Delete scope lets you delete a resource by type and perform actions that delete information about the resource type. For example,
database:delete
lets you delete databases from a database cluster and remove existing users from a database.Each custom scope correlates to one public API endpoint.
Best,
Bobby
Hey @ethandelong,
Great idea, sounds like it’d be super useful!
It looks like someone has had the same idea before and has posted it on our Product Ideas board. The best thing to do would be to head over and add your vote to it, as well as adding any additional information in the comments for exactly what you’d like to see implemented!
Hope that helps!
- Bobby.