# CloudQuery compatibility with ViewOnlyAccess instead of ReadOnlyAccess

**URL:** <https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446>\
**Category:** CloudQuery Plugins\
**Created:** [January 18, 2024, 10:12am UTC](https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446 "2024-01-18T10:12:30Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![certain-alpaca](https://avatars.discourse-cdn.com/v4/letter/c/cc9497/32.png) [@certain-alpaca](https://community.cloudquery.io/u/certain-alpaca)\
**Post date:** [January 18, 2024, 10:12am UTC](https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446/1 "2024-01-18T10:12:30Z")

</div>

CloudQuery using ViewOnlyAccess?

Hey there! I’d like to know if we could use `ViewOnlyAccess` instead of `ReadOnlyAccess` in CloudQuery.

So my question is if you explored whether `ViewOnlyAccess` would be enough for CloudQuery to do its job, or if we will face many permission errors.

---

<div class="post-metadata">

**Author:** ![herman](https://sea1.discourse-cdn.com/flex001/user_avatar/community.cloudquery.io/herman/32/27_2.png) [@herman](https://community.cloudquery.io/u/herman)\
**Post date:** [January 18, 2024, 11:58am UTC](https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446/2 "2024-01-18T11:58:18Z")

</div>

A quick glance at the two policies indicates that `ViewOnlyAccess` provides basic access to 93 unique services, while `ReadOnlyAccess` provides 273.

It’s going to depend on the tables you’re syncing, but that’s quite a difference, so I’d be surprised if `ViewOnlyAccess` didn’t run into more permission errors.

If you’re interested, here are the services not mentioned in `ViewOnlyAccess` but mentioned in `ReadOnlyAccess`. Some of these have corresponding CQ tables, some don’t: [Gist Link](https://gist.github.com/hermanschaaf/45950ed54d38124075f77afd53469cfa)

In any case, we’d always recommend reviewing the tables you need and tailoring your policy to only allow access to the services/resources you’re syncing.

---

<div class="post-metadata">

**Author:** ![ben](https://sea1.discourse-cdn.com/flex001/user_avatar/community.cloudquery.io/ben/32/88_2.png) [@ben](https://community.cloudquery.io/u/ben)\
**Post date:** [January 18, 2024, 1:34pm UTC](https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446/3 "2024-01-18T13:34:38Z")

</div>

While `ViewOnlyAccess` supports some services like `iam`, it only provides access to the `list*` actions and not any of the `Get*`. This is common across many of the other services as well. `ViewOnlyAccess` is intended to only give a very limited view of the AWS account.

If you really want to generate a narrowly permissive policy for your IAM access, I would suggest investigating the `IAM Access Analyzer policy generation` functionality: [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)

This enables AWS to analyze your CloudTrail events and generate a policy based on that activity.

---

<div class="post-metadata">

**Author:** ![certain-alpaca](https://avatars.discourse-cdn.com/v4/letter/c/cc9497/32.png) [@certain-alpaca](https://community.cloudquery.io/u/certain-alpaca)\
**Post date:** [January 18, 2024, 2:13pm UTC](https://community.cloudquery.io/t/cloudquery-compatibility-with-viewonlyaccess-instead-of-readonlyaccess/446/4 "2024-01-18T14:13:44Z")

</div>

Using IAM Access Analyzer for that sounds like a great recommendation indeed, but we would need to repeat that exercise every time we add a new table. The main reason I asked this question is that we would like to prevent any kind of data-related access for compliance reasons.