Capabilities

What the self-hosted build does and does not do: each capability's status, every module that runs with the IAM actions it makes, what is never read, and the versions it is tested on.

The capability matrix for the invitation-only self-hosted build: what ships, what is still in development, what is planned, and what is deliberately never done. The statuses use the public site's three words:

• available now — implemented and test-backed in the build. That is not a claim that a pilot has validated it.
• in development — implemented or partly implemented, with live verification or a production dependency still open.
• planned — a direction with no delivery date. It is not in the build.

Two tests in observability/internal/cli hold this page to the code. TestTheCapabilityMatrixNamesWhatRuns checks that every module the scheduler runs has a row here, that no row names a module it does not run, and that every IAM action a collector makes is listed beside it. TestTheCapabilityMatrixMatchesTheRolesGrants checks each role's section against its CloudFormation template, in both directions: every action the template grants is listed there, and nothing listed there is ungranted.

Scope

• Cloud: AWS, and Google Cloud projects in Estate (BigQuery datasets, service accounts, Firebase apps and Cloud Functions, read through workload identity federation). Azure is planned.
• Deployment: self-hosted, with Docker Compose or the Kubernetes kustomizations in observability/deploy/. A hosted service is planned, after the first self-hosted pilot.
• Licence: offline, verified by the binary alone. The tiers are Essentials (Estate), Professional (Estate and Spend) and Enterprise (Estate, Spend and Provisioning, and the enterprise capabilities). Performance comes with Professional and Enterprise.
• Validation on a live account: one AWS account, the platform's own, was onboarded, collected, alerted on and billed end to end. That covers the external id's negative check, a status change delivered to a webhook, and a delivered Cost & Usage Report reconciled against Cost Explorer. A test estate was brought up and torn down through the product's own Provisioning templates, the agent applying them against that account as the reader role (p7_81). Validation across separate customer accounts is in development.

Capabilities

The reader role

observability/deploy/cloudformation/reader-role.yaml, deployed in every connected account. It grants exactly the actions in the three lists below, and no wildcard. None of them returns S3 object contents, log events, CloudTrail events, CloudFront configurations or Lambda source, each of which can hold a customer's data or credentials. The template lists the reasons, and its test holds the allowlist. Its trust policy lets the platform assume it with the account's external id (sts:AssumeRole), set its source identity (sts:SetSourceIdentity) and tag its session (sts:TagSession).

Called by the inventory collectors

Most run per account and region. S3's and CloudFront's resources have a global identity, so those two run once per account. CloudFront's distributions and Lambda's functions are found from the metrics each publishes, not from their configuration, which carries the origins' custom headers and the functions' environment variables.

Called by the other jobs and by onboarding

Granted ahead of a collector

These were granted when the template was written, for the EC2 collectors still to come: instance types, security group rules, network interfaces, route tables, gateways, endpoints, peering, regions and zones. Each was reviewed as metadata-only. Nothing calls them yet. A collector that starts calling one moves it into its own list, as the NAT gateway collector did and the volume, VPC, subnet, security group and Elastic IP collectors did (p7_80), and one that nobody ever calls is removed from the template.

ec2:DescribeInstanceTypes, ec2:DescribeSecurityGroupRules, ec2:DescribeNetworkInterfaces, ec2:DescribeRouteTables, ec2:DescribeInternetGateways, ec2:DescribeVpcEndpoints, ec2:DescribeVpcPeeringConnections, ec2:DescribeTags, ec2:DescribeRegions, ec2:DescribeAvailabilityZones

The Google Cloud reader

observability/deploy/gcp/reader-role.yaml, a custom role in each connected Google Cloud project, bound to the project's reader service account. The platform signs in by workload identity federation from its own AWS identity and impersonates that account; no key file exists. The role grants exactly the permissions below. No predefined viewer role would do: each reads content somewhere, Datastore entities, a routine's body, a function's environment, or a service account's keys. Cloud Functions are found from their metrics, as Lambda's are. Verification also reads the reader account and the project (iam.serviceAccounts.get, resourcemanager.projects.get).

The report role

observability/deploy/cloudformation/cost-report-role.yaml is deployed only in an account that delivers a Cost & Usage Report, and only for the bucket and prefix that account names. It is the one role that reads object contents: the report's own files, which hold the account's billing line items.

It has no bucket-wide read and no wildcard resource. A bucket encrypted with a customer-managed KMS key also needs a decrypt grant on that key, which the account adds to its own copy. Its trust policy is the reader role's: the external id (sts:AssumeRole), the source identity (sts:SetSourceIdentity) and the session tags (sts:TagSession).

The jobs that are not collectors

Versions