Hi Everyone,
I’m working on a use case and would love to gather insights from the forum. I’d like to explore different perspectives on this scenario and understand the role of IAM Deny in comparison to Just-In-Time (JIT) access.
I’ll try to provide as much detail as possible. This scenario may apply to some organizations but not necessarily all.
Use Case:
In Google Cloud Platform (GCP), roles are defined at the organization level and assigned to identities within a hierarchy. To minimize risk, I have transitioned high-privilege access bindings from being assigned directly to users/principals to a JIT model, since long-term access poses security vulnerabilities.
Future Perspective:
Instead of simply moving to JIT (which is a fair alternative to long-term access), could we build IAM Deny policies to explicitly restrict actions that should not be performed and then use JIT for permitted tasks? (Considering that IAM Deny is already available).
If access bindings are already transitioned to JIT, where and why does IAM Deny become relevant?
What role does IAM Deny play in enhancing IAM security, and does this specific use case fit into it?
Example Scenario:
-
User 1 (myself) previously held the BigQuery Data Admin Role and had access to PII data via a Highly Privileged (HP) Role.
-
To enhance security, the organization decided to restrict continuous access to PII data.
-
As a result, my IAM permissions were moved to a JIT model, allowing access only when explicitly needed, instead of persistent access.
Key Question:
Instead of transitioning to JIT access, could IAM Deny be used to enforce these restrictions?
Would this be a better alternative, or is JIT the more appropriate solution in this case?
Looking forward to your thoughts and discussions!
- Swapnil