Fine grained permissions for client API keys

[TsjipTsjip]

Is there an existing feature request for this?

• [X] I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

It should be possible to define what an API key is allowed to access via fine-grained permissions, just like the server subuser system is right now.

Right now, if an API key is created, the only restrictions that can be placed on the key are the allowed IP's for this key. This is not really enough when you want to follow the principle of least privilege, where an API key is for instance used exclusively for checking the run status of a server periodically. That API key should not be able to submit power actions, etc.

Describe the solution you'd like.

A system like the current subusers system would suffice, with the additional caveat that user permissions should also be observed when calculating permissions for an API key. If a user says the API key should be able to submit power actions, this API key should only be able to do that for servers they have access to.

Being able to select a (set of) server(s) would also greatly improve the ability to lock down an API key, where if a server was not selected during API key creation, that key has no access to API methods of that server at all.

A bare-minimum solution would be to allow admin users to select that a key should only be used for the client API, and not the application API or vice-versa. (See additional context for reasoning.)

Additional context to this request.

This has become a serious issue since panel version 1.8.0, where user API keys of admin users were granted access to the application API retroactively. This is a serious issue, as all services that were using an API key of an admin user are suddenly a big issue if the service becomes compromised, as not only the servers can be impacted but also the entire panel as a whole.

Our temporary solution was to create a dummy normal user with subuser access to the servers, but this is a whole workaround and we would love to see this improved upon in the future.

This request may be similar to https://github.com/pterodactyl/panel/issues/279 , with the distinction that this is about API keys and not about admin users. This could of course be combined into an even more fine-grained system in which users are able to completely lock down what services they use are able to do to their servers.

[DaneEveritt]

Yep — this is on my radar for future releases, basically just replicating that permissions grid over into the client area API key creation system. The internal changes to how we handle API keys should make this a little simpler in the long run too.