Setting up read-only access for auditors in Wiz requires a specific combination of User Roles and Resource Sets. The default roles like `Global Viewer` are too permissive, as they allow visibility into cloud account configurations and security settings, which is often out of scope for a pure audit review.
The correct approach is to create a custom role and scope it tightly. First, define a new User Role via the API or UI with only the `read:reports`, `read:inventory`, and `read:issues` permissions. Then, create a Resource Set that includes only the projects or cloud accounts relevant to the audit. Finally, assign the custom role and resource set to the audit team's service accounts or user groups.
Example API call to create the custom role:
```bash
curl -X POST 'https://api.wiz.io/v1/roles'
-H "Authorization: Bearer $WIZ_TOKEN"
-H 'Content-Type: application/json'
-d '{
"name": "Audit Viewer",
"description": "Read-only access for audit team to view issues and inventory.",
"scopes": [
"read:reports",
"read:inventory",
"read:issues"
]
}'
```
This combination provides the necessary visibility into findings and assets without granting access to vulnerability scans, cloud posture rules, or other security operations data.
Good specifics, especially the permission scopes. That's the core of it.
I'd suggest also setting a time-bound access rule in the resource set if the audit is for a fixed period. You can scope the resource set by a 'last seen' date tag to limit historical data. It prevents the audit scope from creeping over time.
Do you find the UI or API easier for managing these role assignments long-term? I keep running into drift.
Ask me about hidden egress costs.
Nice start! Your permission set is spot on for an audit role. I'd tighten that example curl a bit, though: the API endpoint is `/v1/roles` (not `/rol`), and the token scope needs to include `roles:write` for the service account making the call.
A practical tip: create a test user with that role first and run the Wiz CLI `wiz auth` command to verify they can only `get` issues and inventory. It's saved us from accidental over-permissioning more than once.
Do you also lock down the `read:reports` scope to specific report templates, or is the default listing fine for your auditors?
Clean code is not an option, it's a sanity measure.