Relate Environments to Roles - Risk Countermeasure

[combility]

Is there an existing request for this feature?

• [X] I have searched the existing issues for this feature request and I know that duplicates will be closed

Is your feature request related to a problem?

User Story

As a System Product owner, I don't want my Developers updating my Production data due to fat fingers or not understanding the nature of the request, so the RBAC my System relies on for security is not compromised, resulting in destructed data.

Context

• Three environment settings configured, Dev, Test and Prod.
• We've common requests re-used across different environments via the Environment drop box in upper right-hand corner. Sweet.

Challenge

• When exposing to Developers during SDLC discovery and build phases, Dev / Test Env, request away, POST, PATCH, no problem.
• If they choose Prod. there's potential to do damage, depending on the potential of POST, PUT, PATCH and DELETE requests.

Describe the solution you'd like

Option 1

Relate Postman IDE/DOM background colour to an Environment value.

Admins enter their desired Environments and chosen Background colours, fully custom. Then on change Environment, background colour change, in your face; fore-armed is fore-warned approach. Other thick clients have this type of configuration; you log in, you see Red: think "Hey, don't put production data here, you're in the Test environment" etc etc.

Option 2

Lock Writable methods to Roles (or some equiv Postman security construct)

POST, PUT, PATCH and DELETE execution request could perhaps be limited to a select group (or anyone by default) Then by Environment perhaps even. (POST OK in Development for Role X, but not POST in Production) So sure, they could see the request (so discoverability not compromised), not be limited to adding new writable requests (so collaboration is cool), but at the point of executing them in a given Environment; that gets determined by their Role.

Describe alternatives you've considered

Settings & Teams

Expose Prod collections & settings ONLY to a trusted team outside of the Developers / Support. That may be the best way ...?

Risk Transfer to Source System

Manage at the credential > source API layer. Though I've seen some funky security constructs that can't discern security between methods for a given account; we don't have control over source security layer, vendors documentation is often lacking and some product admins have no idea.

Prompt

I found a similar feature request here promoting prompts prior to execution. That's got its place in some scenarios though felt like UI friction.

https://github.com/postmanlabs/postman-app-support/issues/3976

Additional context

No response

[giridharvc7]

Have you tried pinning dev and beta to the collections and leave prod out?

[combility]

Have you tried pinning dev and beta to the collections and leave prod out?

Hi thanks, no, I wasn't aware of that pinning feature...that looks really good!

So Collection>Team lockdown Collection>Environment ... that will work :)

Thank you!