Change history

WRING View shows, for every resource it lists, the last change that touched it: a deploy, a Terraform run, or a configuration change someone made in a console, a CLI or an SDK — who made it, when, and what changed, in a sentence. The same history explains cost anomalies ("the NAT gateway settings changed two days before the spike").

It is read from your cloud's own audit log: management events only — which API call changed which resource, when, and the name of the person or pipeline that made it. The audit log hands each event over whole; WRING looks at a few of its fields to classify it (the user agent says whether a console, a CLI or Terraform made the change; a handful of request parameters, such as an instance type or a volume size, become the sentence) and stores only that allowlisted part. It never stores IP addresses, user agents, request or response bodies, tag values or your data, and it keeps names and emails for 13 months at most.

Where a cloud account is not connected yet, the resources drawer says so ("Change history is not connected for … · Set it up"). Here is what each cloud needs.

AWS

Add the Wring Change history level to the account in the install wizard (Linked accounts → the account → install levels). It launches a small CloudFormation stack with one role, WringChangeHistory-…, that may call exactly one read-only action:

{ "Sid": "ChangeHistoryRead", "Effect": "Allow", "Action": ["cloudtrail:LookupEvents"], "Resource": "*" }

CloudTrail event history is on by default in every AWS account, keeps 90 days and costs nothing. If the account already has the Wring Security level, change history is read through that role until you add this one.

Google Cloud

Two grants for WRING's service account (the one your billing export grant names), both read-only.

1. Billing Account Viewer on the billing account you connected. WRING reads the audit log only of projects that are billed to that billing account — this is how it makes sure a project is yours. A project billed elsewhere is skipped and shows as "not connected" in the resources drawer, whatever the export says.

gcloud beta billing accounts add-iam-policy-binding BILLING_ACCOUNT_ID \
  --member=serviceAccount:WRING_SERVICE_ACCOUNT \
  --role=roles/billing.viewer

2. Logs View Accessor on each project's _Required log view. That bucket holds Admin Activity audit logs — always written, never charged — and never your application logs.

Per project:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:WRING_SERVICE_ACCOUNT \
  --role=roles/logging.viewAccessor \
  --condition='title=wring-change-history,expression=resource.name == "projects/PROJECT_ID/locations/global/buckets/_Required/views/_AllLogs"'

Or once for your organization (or a folder, with resource-manager folders add-iam-policy-binding). The condition matches every project's _Required view and nothing else — not the organization's or a folder's own view, whose org-level audit logs WRING never reads:

gcloud organizations add-iam-policy-binding ORG_ID \
  --member=serviceAccount:WRING_SERVICE_ACCOUNT \
  --role=roles/logging.viewAccessor \
  --condition='title=wring-change-history,expression=resource.name.startsWith("projects/") && resource.name.endsWith("/locations/global/buckets/_Required/views/_AllLogs")'

Azure

Reading the Activity Log needs Microsoft.Insights/eventtypes/*. If your subscriptions are connected through Azure Lighthouse, nothing is needed: the delegation already includes Reader. If you connected with Connect with Microsoft, add this custom role for WRING's app (Cost Management Reader does not include the Activity Log). A custom role's name is unique in your directory, so create it once, with every subscription you connect among its assignable scopes, then assign it per subscription:

az role definition create --role-definition '{
  "Name": "WRING Activity Log Reader",
  "Description": "Read the Activity Log (management events) for WRING View change history.",
  "Actions": ["Microsoft.Insights/eventtypes/*"],
  "AssignableScopes": ["/subscriptions/SUBSCRIPTION_ID_1", "/subscriptions/SUBSCRIPTION_ID_2"]
}'
az role assignment create --assignee WRING_APP_SERVICE_PRINCIPAL_ID \
  --role "WRING Activity Log Reader" --scope /subscriptions/SUBSCRIPTION_ID_1
az role assignment create --assignee WRING_APP_SERVICE_PRINCIPAL_ID \
  --role "WRING Activity Log Reader" --scope /subscriptions/SUBSCRIPTION_ID_2

For a whole management group, put /providers/Microsoft.Management/managementGroups/GROUP_ID in AssignableScopes instead (a custom role may name one management group there) and assign the role once with that as --scope. A subscription you connect later: add it to AssignableScopes with az role definition update, then assign the role there.

Deploys and Terraform runs

Deploy markers and Terraform Cloud notifications need no grant. A marker may name the resources it changed (resources, up to 100 ids or ARNs), its author and repo; a marker without resources is matched to the resources whose service, app or app.kubernetes.io/name tag carries its service.

After you grant access, the history appears within the hour, and the last 90 days are filled in over the following hours.