DigitalOcean home
  • Droplets
  • Spaces
  • Kubernetes
  • Tools & Integrations
  • One-click Apps
  • API Documentation
  • Community
  • Tutorials
  • Q&A
  • Projects
  • Meetups
  • Customers
  • Pricing
  • Docs
  • Support
  • DigitalOcean home
  • Products
    • Droplets

      Scalable compute services.

    • Spaces

      Simple object storage.

    • Kubernetes

      Run managed Kubernetes clusters.

    • Tools & Integrations

      Automate your infrastructure.

    • One-click Apps

      Deploy pre-built applications.

    • API Documentation
  • Customers
  • Community
    • Community Overview

      Connect, share and learn

    • Tutorials

      DevOps and development guides

    • Questions & Answers

      Development and systems Q&A

    • Projects

      Community-built integrations

    Get Involved
    Write for DOnations
    Join us at a Meetup
    Featured Post
    An Introduction to Kubernetes

    by Justin Ellingwood

  • Pricing
  • Docs
  • Support
    • Documentation

    • Contact Support

    • Network Status

  • Home /
  • DO-I-966 /
  • New idea
55 Vote

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
  • Future consideration
Developer API
  • Comments (13)
  • Votes (55)
  • Merged ideas (2)
  • Attach files
  • Dan Sherry commented
    7 Oct, 2020 09:38pm

    ETA? Pretty big security issue... I want to automate volume snapshots for a single droplet without granting access to all resources.

    ×

    Attachments Open full size

  • Marco De Nittis commented
    21 Sep, 2020 11:22pm

    Same as https://ideas.digitalocean.com/ideas/DO-I-626

    ×

    Attachments Open full size

  • Jake Malley commented
    3 Aug, 2020 07:25pm

    Likewise, this is my primary use case - using dns01 challenges to create LE certificates from cert-manager on a Kubernetes cluster. It seems a no brainer to implement this - I don’t like the idea of giving cert-manager full access to my DO account.

    ×

    Attachments Open full size

  • Dimas commented
    2 Aug, 2020 07:42pm

    my use case primarily (for now) being "lets-encrypt" DNS access to TXT record read/write

    ×

    Attachments Open full size

  • Jason Forbes commented
    5 Sep, 2019 03:57am

    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

  • S commented
    13 Aug, 2019 03:58pm

    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

  • Anonymous commented
    11 Sep, 2018 04:35pm

    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

  • Patrik Karisch commented
    11 Sep, 2018 04:35pm

    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

  • Joshua Cooper commented
    11 Sep, 2018 04:35pm

    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

  • Safeharbour commented
    11 Sep, 2018 04:35pm

    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

  • Anonymous commented
    11 Sep, 2018 04:35pm

    limit API options for specific team members

    ×

    Attachments Open full size

  • Anonymous commented
    11 Sep, 2018 04:35pm

    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

  • Maria Kirschbaum commented
    11 Sep, 2018 04:35pm

    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

  • 18 Vote

    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...
    Created 14 Dec 02:44pm by Duncan Berriman
    Developer API
    0 Future consideration
  • 19 Vote

    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 ...
    Created 14 Nov 02:48pm by Guest
    Developer API
    0 Future consideration
Log in / Sign up

Identify yourself with your email address

Subscribe

You won't be notified about changes to this idea.

Related ideas

Busy.b7e3690b94c43e444483fbc7927a6a9a
DigitalOcean home

© 2018 DigitalOcean, LLC. All rights reserved.
Proudly made in NY

  • Twitter
  • Facebook
  • Instagram
  • YouTube
  • LinkedIn
  • Glassdoor
Company
About
Leadership
Blog
Careers
Partner Network
Referral Program
Events
Press
Legal & Security
Products
Droplets
Spaces
Kubernetes
Tools & Integrations
One-click Apps
API
Pricing
Documentation
Release Notes
Community
Tutorials
Meetups
Q&A
Write for DOnations
Droplets for Demos
Hatch
Shop Swag
Research Program
Currents Research
Open Source
Support
Contact Support
FAQ
Network Status