Resource Ownership
Resource ownership answers one question for every resource you have synced: who is responsible for it?
You write a short list of rules. CloudQuery Platform reads the rules and gives each resource an owner. The owner is then a column you can filter by, a way to group the inventory, and a table you can query.
An owner is a plain piece of text, such as payments-team or [email protected]. CloudQuery Platform does not keep a list of valid owners. The owner is whatever your rules produce.
How It Works
You configure an ordered list of rules. For each resource, CloudQuery Platform does this:
- It reads the rules in order, from the top.
- It stops at the first rule that gives that resource an owner. The rules below it are not applied to that resource.
- It writes the result to the
resource_ownershiptable, together with the rule that produced it.
A resource has one owner, or none. A resource that no rule matches stays unowned.
Apps get their owners from their resources. An app’s owners are the distinct owners of the resources in it, so an app whose resources belong to two teams has two owners. See Apps and Environments.
When the Rules Run
The rules run:
- After each sync completes.
- When you save a change to the rules.
Rules are applied in the background. Until the first run finishes, nothing is owned.
Nothing Is Owned by Default
Ownership is something you turn on. A new organization has no rules, so every resource is unowned until you write your first rule.
Writing the Rules
- In the sidebar, click your user icon and select Organization settings.
- Open the Resource ownership page.
Click Add rule and select a rule type. Drag the rule cards to change their order, because the first match wins. Use the switch on a card to turn a rule off without deleting it. Click Save changes when you are done.
Rule Types
| Rule type | Where the owner comes from |
|---|---|
| Resource tags | The value of a tag on the resource |
| Custom SQL | A query you write against any table you have synced |
Resource Tags
Enter one or more tag keys, such as owner, team, or service. A resource that carries one of these keys is owned by the value of that tag.
The keys are in priority order. If a resource carries two of the keys, the first key in your list is used.
Tag keys are matched without regard to case, so the key owner also reads a tag written Owner. The field suggests keys that are really present on your resources, with the number of resources that carry each one. A tag with an empty value is ignored, so the resource falls through to the next rule.
Custom SQL
Use this rule when the owner lives in another system rather than in a cloud tag. Any table you have synced can be queried, so ServiceNow, GitHub, env zero and the rest are all available.
Write a SELECT that returns:
- Exactly one column named
owner. - At least one more column, which says which resources that owner applies to.
CloudQuery Platform does the join for you. Do not join to cloud_assets yourself.
For example:
SELECT account_id AS account, assigned_to AS owner
FROM servicenow_cmdb_ci_cloud_service_accountThis says “in each AWS account, the owner is whoever ServiceNow records for it”. You can match on more than one column at a time, so a query returning account and region gives one team the resources in us-east-1 and another team the resources in eu-north-1.
These are the columns you can match on:
| Column | Matches on |
|---|---|
account | The cloud account id |
account_name | The cloud account name |
cloud | The cloud, such as aws |
region | The region |
name | The resource name |
resource_type | The resource type, such as aws_s3_buckets |
resource_type_label | The readable name of the resource type |
resource_category | The category of the resource type |
app_id | The id of the app the resource belongs to |
app_name | The name of the app the resource belongs to |
environment | The environment the resource runs in |
_cq_platform_id | One resource, by its platform id |
_cq_source_table | The table the resource came from |
The rule is checked before you can save it. A query is rejected when it has no owner column, more than one owner column, or nothing to match on. It is also rejected when it returns a column that is not in the table above; the error names that column.
A row that matches no resource is ignored, so a record for an account you have closed does nothing. Write your query so that each resource gets one owner: if two rows match the same resource, the winner is stable but arbitrary.
Checking a Rule Before You Save
Every rule card shows what that rule would do: how many resources it would own, and the busiest owners it would produce. The count is what the rule catches in its current position, so a rule you drag up or down changes what it reports.
Below the rules, the Ownership preview shows the result of the whole list. Switch between:
- By owner — each owner and the number of resources they would get. Click an owner to see the resources.
- By app — each app and the owners its resources would get.
The preview also warns you about two mistakes:
- A rule that could not run, which is nearly always a SQL rule with an error in its query.
- A rule that is never evaluated, because a rule above it already owns everything left.
Nothing is saved while you preview. Click Save changes to apply the rules.
Letting the AI Assistant Write the Rules
At the top of the page, click Recommend rules. The AI Assistant reads your data — which tag keys you use, how much of your estate each one covers, and which ownership sources you have already synced — and proposes a complete set of rules.
Review the recommendation, drop any rule you do not want, and click to apply it. Applying fills in the form; it does not save. You still click Save changes yourself.
The recommendation is the whole policy, so applying it replaces the existing rules. The screen asks you to confirm before it does.
You can also ask the assistant in conversation, for example Which tag should I use to set owners? or Add a rule that gives the payments account to payments-team. The assistant reads your current rules, shows you what a change would do, and asks before it saves anything. This needs the assistant to be in Full Access mode.
Using Ownership in the Asset Inventory
Owner Column
The Asset Inventory shows an OWNER column beside the resource name. A resource that no rule owns shows a dash.
Filter by Owner
Add an Owner filter in the filter bar to show the resources of one or more owners. The values offered are the owners your rules produced. Combine the Owner filter with any other filter.
Group by Owner
Select Owner in the Group by control. The inventory then shows one group for each owner, with its resource count, and an Unowned group for the resources that belong to nobody. Open the Unowned group to see the gaps in your rules.
Resource Details
Click a resource to open the detail panel. An Ownership card shows the owner of that resource, and a Configure ownership button takes you to the rules.
Querying with SQL
Ownership is a ClickHouse table, so you can query it in the SQL Console and use it in reports.
Tables
| Name | One row for | Key columns |
|---|---|---|
resource_ownership | Each resource that a rule owns | _cq_platform_id, owner, resource_table, rule_id, source, source_metadata |
apps | Each app | id, name, owner_team_names |
_cq_platform_id identifies one resource across all tables. Use it to join resource_ownership to cloud_assets and to the per-resource tables.
source is the type of rule that produced the row, such as tags or sql. source_metadata is the evidence for that type — the tag key that was read, or the column values that were matched. rule_id is the rule itself, and it survives reordering, so you can count how much work each rule is doing.
List the Resources of Each Owner
SELECT owner, resource_table, _cq_platform_id
FROM resource_ownership
ORDER BY ownerCount the Resources of Each Owner
SELECT owner, count() AS resources
FROM resource_ownership
GROUP BY owner
ORDER BY resources DESCSee How Much Each Rule Owns
SELECT source, rule_id, count() AS resources
FROM resource_ownership
GROUP BY source, rule_id
ORDER BY resources DESCJoin to the Asset Inventory
cloud_assets holds one row for each source that reported a resource. Keep one row for each resource before you join:
SELECT o.owner, c.cloud, c.resource_type, c.name
FROM (
SELECT _cq_platform_id, cloud, resource_type, name
FROM cloud_assets
ORDER BY _cq_sync_group_id DESC
LIMIT 1 BY _cq_platform_id
) c
JOIN resource_ownership o ON o._cq_platform_id = c._cq_platform_id
WHERE o.owner = 'payments-team'Find the Resources That Nobody Owns
SELECT _cq_platform_id, cloud, resource_type, name
FROM cloud_assets
WHERE _cq_platform_id NOT IN (SELECT _cq_platform_id FROM resource_ownership)
LIMIT 1 BY _cq_platform_idFind the Owners of Each App
SELECT name, owner_team_names, resource_count
FROM apps
ORDER BY resource_count DESCProgrammatic Access
You can read and write the rules through the Platform API, which is useful if you keep your configuration in source control.
| Endpoint | What it does |
|---|---|
GET/PUT /resources/ownership-policy | Read or replace the ownership rules |
POST /resources/ownership-policy/preview | Report what a candidate rule set would own, without saving it |
POST /resources/ownership-policy/preview/resources | List the resources a candidate rule set would give one owner |
GET /resources/ownership-policy/tag-keys | List the tag keys present on your resources |
GET /resources/inference-signals | Summarize the tags and accounts a rule could match on |
A PUT replaces the whole rule set, so send back the rules you want to keep. A rule you leave out is deleted.
In the asset endpoints, the reserved column _cq_owner filters by owner. For example, _cq_owner = "payments-team" selects one owner, and _cq_owner IS EMPTY selects the resources that nobody owns.
See the Platform API Reference for the full request and response formats.
Before Ownership Rules
Organizations that have not enabled ownership rules see an older screen in the same place. It holds a plain list of tag keys, such as org, business_unit or team. Those keys become filter dimensions in Insights and are shown on the resource detail view, in the order you list them. They do not change how your data is synced or stored.
Ownership rules replace that screen. A tags rule does the same job and tells you how many resources it covers before you save.
Next Steps
- Asset Inventory - filter and group your resources by owner
- Apps and Environments - group resources by the product they serve
- SQL Console - query the ownership table directly
- AI Assistant - ask the assistant to write your rules
- Data Model - how CloudQuery Platform organizes your synced data
Last updated on