Cloud inventory
AWS and Kubernetes, and how they correlate
Edit this pageOn this page
Loomscope discovers AWS and Kubernetes resources from the control plane, never from a daemon. That is a hard rule in the codebase: a daemon host holds no cloud credentials, so a compromised scanner gets an attacker a scanner, not your AWS account.
What is covered
| Provider | Resources | Sync interval |
|---|---|---|
| AWS | EC2, VPC, subnets, RDS, ELB, Lambda, EKS, security groups | 15 minutes |
| Kubernetes | Nodes, pods, services, ingresses | 5 minutes |
Both also sync on demand from the account page.
Adding an account
Settings → Cloud → Add account. Use read-only credentials — Loomscope never writes to a cloud provider, and a credential that cannot write is a credential that cannot be misused if the database is stolen.
For AWS, a role with ReadOnlyAccess or a narrower policy covering the
services above. For Kubernetes, a kubeconfig or in-cluster service account
with get/list/watch on the resources above.
Credentials are stored in the credentials table, encrypted at rest with
AEAD keyed by LOOMSCOPE_KMS_KEY. See Credentials.
Correlation with scanned hosts
This is the part that makes cloud inventory worth having rather than a second list to reconcile by hand.
Cloud resources are matched against scanned hosts where they line up — an EC2 instance and the host discovered at its private address become one thing, not two. A pod discovered in Kubernetes and the container found by Docker discovery on that node are the same workload.
Where correlation fails, both records remain visible rather than one being silently dropped. A cloud resource with no matching scanned host is worth noticing: it is either unreachable from any daemon, or nothing is scanning that network.
What this tells you that scanning cannot
- Resources that exist but do not answer. A stopped instance, a Lambda function, an empty security group.
- Intent rather than observation. A security group says what is permitted; a port scan says what is listening. The gap between them is usually the interesting part.
- Names and tags. Cloud metadata carries ownership and purpose that no amount of probing recovers.
What it does not do
- It does not change anything. Read-only, by construction.
- It does not cover every service. The list above is the list.
- It is not a CSPM. Loomscope inventories cloud resources and correlates them with what it discovered on the network; it does not evaluate them against a compliance benchmark.
Air-gapped deployments
Cloud discovery is the one feature that inherently requires network access to a third party. It is off unless an account is configured, and an air-gapped install simply does not configure one. Nothing else in the product reaches out.