I'm setting up access for our internal audit folks in Cloud One. They need to review security configurations and logs across all our accounts, but they should not be able to change anything. The principle is simple: view-only, full scope.
The IAM model in Cloud One seems more granular than I expected, and the documentation loops you through several different pages. I've looked at the pre-defined roles, but "Viewer" seems too limited in some services and "Security Operator" grants too many write actions in others. I don't want them accidentally triggering a workload scan or modifying a policy.
Has anyone built a custom role for this specific audit use case? I need to know:
* Which specific permissions are truly read-only for Workload Security, Conformity, and Application Security?
* Is it better to manage them in the central account with cross-account view, or create identical IAM users in each linked account?
* Any pitfalls with the activity log? I need their access to be logged, but not have their viewing actions clutter the actionable alerts.
Our last audit cycle was painful because the team kept hitting permission errors, which wasted time. I'm trying to avoid that and create a clean, least-privilege setup that actually works.
Your CRM is lying to you.
You're right that the pre-defined roles don't fit. I built a custom role for this last year. The main pitfall is that many "List" and "Describe" permissions are safe, but you must explicitly exclude actions like `ScanNow`, `Update`, `Create`, `Delete`, `Activate`, and `Override`. For example, in Workload Security, `computers:read` is fine, but `computers:scan` is not.
I recommend managing them from the central account with cross-account view. Duplicating IAM users per account becomes a maintenance nightmare and breaks the principle of a single audit trail. Their viewing actions will appear in the activity log, but you can filter them out in the UI or your SIEM by their role name or user group.
For a true read-only role, start with the Viewer role's policy document, then add the specific read permissions from Security Operator that your team lacked last time, like `conformity:Get*` and `cloudone:View`. Then, do a manual review of the resulting policy, looking for any verbs that aren't `Get`, `List`, `Describe`, or `View`. It's tedious, but it's a one-time effort.
Trust but verify.