We've released an expansion to our handling of API keys on Runpod. Previously, you were able to create API keys with read or read and write permissions, but now you can scope keys by endpoint and have more fine-grained control over what your keys allow access to. Here's a TL;DR summary of new features available with the update:

• View created and last used dates for API keys
• Disable and re-enable keys as needed
• Differentiate access levels for endpoint and GraphQL access
• Allow read/write, read only, or no access to any or all endpoints on a per-endpoint basis

All of your existing keys will continue to function as they have been, so if you don't have a need for the new features, you can keep using your existing keys without issue. If any of this sounds useful to you, read on for the scoop!

Setting Up Your New API Key Permissions

Your keys are in the same spot they have been, under your Settings page. All existing keys have already been migrated and will remain in their legacy format without any additional features, so to begin using the new features you'll need to create some new keys. Any new keys will be created with an rpa_ prefix. You can also enable or disable any key (legacy or not) with the slider.

There are two main level of permissions at play here:

• GraphQL access - This allows you to create, edit, and delete numerous items associated with your account, including endpoints and pods as described in our GraphQL documentation. Note that this is an extremely powerful level of access - treat it appropriately.
• Endpoint access - This allows the associated keys access to specific endpoints on a per-key basis, and you can admit or revoke access as you see fit.

Why is this important?

We released this because while API keys are a very powerful feature, they are also a direct link to your account, and by extension your account balance. This is especially true with GraphQL permissions; theoretically a leaked key could allow a user to create pods under your account for nefarious means (e.g. Bitcoin mining for profit on your dime.) No one wants that, so we want to ensure that you have as many options as possible to manage your account's security. We highly suggest you always follow the principle of least privilege when doling out access in general, and most specifically never allow read/write GraphQL access for longer or for more individuals than you absolutely need.

Questions? Feel free to pop on our Discord or ask our support team!

‍

Author profile: Brendan McKeag