CloudQuery

CloudQuery News
Product News
Security

Introducing Data Access Control for CloudQuery Platform

Your security team doesn't need to see DevOps staging environments. Your finance team shouldn't access production databases. But when everyone queries the same CloudQuery Platform, they see everything by default.
Today, we're introducing Data Access Control for CloudQuery Platform - role-based access control (RBAC) with SQL-based permissions that let you control exactly who sees what in your multi-tenant environment.

The Multi-Tenant Access Challenge #

Cloud environments change constantly. You add new AWS accounts, teams reorganize under different organizational units, projects move between regions. Manual access management breaks down fast.
Without Data Access Control, everyone using your shared CloudQuery Platform instance sees all synced data. Your security team sees DevOps staging environments. Your finance team can query production databases. Teams working in different regions see each other's resources. This creates security concerns, data overload, and compliance challenges.
Before Data Access ControlAfter Data Access Control
Everyone sees all data in the shared PlatformGranular, role-based access control per user/team
Manual permission workarounds that don't scaleAutomatic role assignment via SSO group mapping
Security concerns from over-broad accessSQL-based permissions control exactly who sees what
Update access manually when accounts addedPermissions adapt automatically to new resources

SQL-Based Permissions Make It Easy #

Here's what makes this easy: if you can write a WHERE clause, you already know how to define permissions. That's it. No new syntax to learn, no complex permission language. Just the SQL you already use for queries.

Example: Restricting Access by Organizational Unit #

Let's say you want your finance team to only see AWS accounts under the "Production-US" organizational unit. Here's the SQL query:
SELECT ca._cq_platform_id
FROM cloud_assets ca
JOIN aws_organizations_account_parents p ON p.id = ca.account
JOIN aws_organizations_organizational_units ou ON ou.id = p.parent_id
WHERE ou.name = 'Production-US'
Create this Data Permission in the Platform UI, bundle it into a "Finance Team" Data Access Role, then map that role to your "finance" SSO group in Okta or Azure AD. Done. Finance team members automatically see only Production-US resources when they log in.

More Examples #

Restrict to a specific region:
SELECT _cq_platform_id
FROM cloud_assets
WHERE region = 'us-east-1'
Limit to IAM resources only:
SELECT _cq_platform_id
FROM cloud_assets
WHERE resource_type LIKE 'aws_iam%'
   OR resource_type LIKE 'gcp_iam%'
You can combine multiple permissions in a single role. A security auditor role might include both the organizational unit restriction and the IAM resources filter.

Common RBAC Use Cases #

Multi-tenant SaaS teams: Restrict each customer's cloud infrastructure data to their respective team members using role-based permissions
Finance & cost optimization: Give finance teams access to cost data across all AWS, GCP, and Azure accounts without exposing security-sensitive resources
Security & compliance auditors: Grant read-only access to IAM policies and security groups without production database visibility
Regional teams: European team sees only eu-west regions, US team sees only us-east/us-west resources
Compliance & governance teams: Access to compliance-relevant resources (IAM, network configs, security policies) without full infrastructure access

What You Need to Know #

Permissions add up, they don't subtract. If Permission A grants access to all production accounts and Permission B grants access to all staging accounts, users see both. You can't use a third permission to then hide specific resources within those sets. Design your permissions with this in mind from the start.
Query complexity affects performance. Joins across multiple tables or complex filters slow down the UI and SQL Console for users with those permissions. Target your queries to the access pattern you need.
Built-in roles take precedence. Data Access Roles don't affect users with Admin or Write roles assigned. Only users without Admin or Write roles see permission restrictions. Data Access Roles automatically inherit permissions from the General:Read baseline role.

Get Started with Data Access Control #

Data Access Control brings role-based access control to CloudQuery Platform with SQL-based permissions that adapt to your changing cloud environment. Control who sees what using the SQL you already know, automate role assignment through SSO groups, and manage everything through our UI or API.
Ready to implement RBAC for your team?
Need help implementing Data Access Control? Contact our team or join the CloudQuery Community to connect with other users and experts.

Related posts

Turn cloud chaos into clarity

Find out how CloudQuery can help you get clarity from a chaotic cloud environment with a personalized conversation and demo.


© 2025 CloudQuery, Inc. All rights reserved.