Control IP Access list for project-only API keys at the project-level exclusively
When setting up API keys as a project owner, you only get one opportunity to manage the access list without getting an Organization Owner to modify it thereafter.
This creates a bottleneck where users need to ask for their API key access list to get changed (or alternatively make a new keypair, and have the API Keys list cluttered).
If a key is only being used in one project, it should be allowed by the project owner to update the access list at any time since there is no risk of it affecting the organization.
-
Guillaume commented
An API key with Project owner (GroupOwner) role should also be able to update another API key IP access list in that same PROJECT.
-
Callum Gardner commented
Our frustration is in development environments specifically, where fine-grained access-controls like this aren't needed, and employees should be able to access the more restricted APIs without requiring IP whitelisting. (In staging and production environments this isn't necessarily an issue as these environments are more controlled.)
The IP whitelisting is especially frustrating when many employees are WFH because the public IP addresses can change, unless employees have purchased a static IP address for their homes. (Most people don't do this.)
In short, I'd like a user to be capable of managing their own API keys, rather than needing to escalate the issue to the Organisation Owner, in our case the Director of Engineering, each time.