cloudlist: one asset inventory across every cloud provider

An inventory tool, not a scanner

cloudlist is a multi-cloud tool for getting assets from cloud providers. The README is explicit about who it is for and why: it is intended to be used by the blue team to augment attack surface management efforts by maintaining a centralized list of assets across multiple clouds with very little configuration effort.

That framing matters, because it sets expectations. cloudlist does not find vulnerabilities, it does not scan, and it does not tell you what is exposed. It tells you what exists, in one place, on a schedule if you want. Everything else, the attack surface management workflow around it, is what the blue team builds on top.

The word assets is doing the specific work here. The tool queries each provider's API and returns the resources it manages, and the service and provider flags in the help output show the shape of the model: providers on one axis, services on the other, so you can ask for the public IPs across AWS, or the DNS records across Route53, or the droplets across DigitalOcean.

The project is from ProjectDiscovery, the team behind the Nuclei and subfinder line of tools, and it is MIT licensed with a Go Report Card badge, a contributions-welcome badge and the usual set of links. The documentation lives on the ProjectDiscovery docs site under tools/cloudlist, with separate pages for installation, usage, running and the supported providers. The default branch is dev, and the last push was on 2026-10-14, the same day as the 1.5.0 release.

Eighteen providers, and how to add one

The provider list in the default value of the provider flag is the clearest statement of scope, and it is long: linode, fastly, heroku, terraform, digitalocean, consul, cloudflare, hetzner, nomad, do, scw, openstack, alibaba, aws, gcp, namecheap, kubernetes and azure, with custom as the last entry.

The range is broader than the name suggests. Terraform is in there, which is how you list the infrastructure a Terraform state file describes rather than the live account. Kubernetes is in there, so a cluster is a provider. Consul and Nomad are in there, so service discovery systems are sources. And custom is there as an extension point for a provider the project does not ship.

That is what the feature list means by highly extensible making adding new providers a breeze, and the contribution guide points at two documents for it: PROVIDERS.md and DESIGN.md. The workflow the README gives is the usual fork, branch, commit, push, pull request sequence, with the branch named new-provider.

The service axis is equally long, with a default list that names the specific resources the tool can pull: cloudfront, gke, domain, compute, ec2, instance, cloud-function, app, eks, consul, droplet, vm, ecs, fastly, alb, s3, lambda, elb, cloud-run, route53, publicip, dns, service, nomad, lightsail, ingress and apigateway, again with custom at the end.

The result is a tool where the interesting query is usually a cross product, and the tool is designed to make that a one-line change.

Keyless authentication, and discovering providers automatically

Two features remove most of the configuration burden, and they are the ones that make the tool usable in a scheduled job.

The first is keyless authentication support, specifically AWS IRSA and instance profiles, and GCP workload identity. If your pipeline already runs inside AWS or on GCP with an attached role, cloudlist can use that identity rather than asking you to hand it a static key. The service account or instance profile already has a policy, and the tool simply uses it.

The second is the auto-discovery flag, -ad and -auto-discovery, which discovers providers from environment credentials instead of from the provider config file. The list it looks for is aws, gcp, azure and kubernetes. In other words, if the environment you run the tool in already has credentials for a cloud, the tool finds that cloud on its own, which is the difference between a tool that works in CI and a tool that needs a config file mounted into every job.

Without auto-discovery, the configuration is two files with fixed default paths. The main config file is $HOME/.config/cloudlist/config.yaml, and the provider config is $HOME/.config/cloudlist/provider-config.yaml, with -config and -pc and -provider-config to override them.

The design consequence is that there are two authentication paths, ambient and explicit, and the explicit one is the one that puts credentials in a file on disk. For a team running this on a schedule, the ambient path is both simpler and the one with a smaller blast radius, because there is no long-lived key to leak.

Filters and output formats

The flags section of the help output is where you can see the whole interface, and the flags fall into four groups.

Usage:
  ./cloudlist [flags]

Flags:
CONFIGURATION:
   -config string                cloudlist flag config file (default "$HOME/.config/cloudlist/config.yaml")
   -pc, -provider-config string  provider config file (default "$HOME/.config/cloudlist/provider-config.yaml")
   -ad, -auto-discovery          discover providers from environment credentials (aws, gcp, azure, kubernetes) instead of the provider config

FILTERS:
   -p, -provider value          display results for given providers (comma-separated) (default linode,fastly,heroku,terraform,digitalocean,consul,cloudflare,hetzner,nomad,do,scw,openstack,alibaba,aws,gcp,namecheap,kubernetes,azure, custom)
   -id string[]                 display results for given ids (comma-separated)
   -host                        display only hostnames in results

The filters are where the tool earns its keep. You can restrict the output to given providers, to given identifiers, to hostnames only or to IP addresses only, and to given services, and you can exclude a service for a provider and exclude private addresses from the command line output. The last one matters more than it looks: an inventory that mixes private and public addresses is less useful for attack surface work than one that can hand you the public list.

The output group is small and deliberately pipe friendly. There is -o and -output for a file, -json for JSON output, -silent for results only, -v for verbose output and -version. The feature list calls out stdout support to work with other tools in pipelines as its own bullet, which is the point of the tool in an ASM pipeline: cloudlist emits, and something else consumes.

There is also an update group, with -up to update cloudlist to the latest version and -duc to disable the automatic update check, which matters on a machine that should not phone home.

GCP gets two different discovery strategies

Most providers have one way of listing, and cloudlist calls it. GCP has two, and the documentation has a dedicated file for it, docs/GCP_ASSET_API.md.

The organization-level Asset API gives comprehensive organisation-wide discovery using the Cloud Asset Inventory API. The individual service APIs give fast, project-specific discovery using the individual GCP service APIs. The setup instructions, required permissions, service account configuration and usage examples are all in that document.

The distinction is a real operational one. The individual service APIs mean one API call per service type, which is fast and precise but only sees the project you have credentials for. The Cloud Asset Inventory API is one query that returns everything in the organisation, which is what an inventory wants, and it is the difference between a partial asset list and a complete one.

The repository also has an examples/ directory with a file called gcp-short-lived-credentials.yaml, which suggests the other half of the story: how to authenticate to the inventory without leaving a long-lived key behind, which is what short-lived credentials are for and which is consistent with the keyless authentication the feature list advertises.

For the rest of the providers, the pattern the project follows is the same one the go.mod shows, one vendor SDK per provider, called through a common interface so the tool can iterate over them uniformly.

One SDK per provider, behind a common interface

The go.mod is a directory of cloud provider SDKs, and reading it tells you how much of the work is integration rather than logic.

For AWS there is the aws-sdk-go, for GCP the google.golang.org/api, for Cloudflare the cloudflare-go, for DigitalOcean the godo, for Fastly the go-fastly, for Hetzner the hcloud-go, for Heroku the heroku-go, for Linode the linodego, for Namecheap the go-namecheap-sdk, for Scaleway the scaleway-sdk-go, for Alibaba the alibaba-cloud-sdk-go, for ArvanCloud the arvancloud cdn-go-sdk, and for the OpenStack family the gophercloud. Service discovery systems come with the hashicorp consul and nomad APIs, and Kubernetes with the client-go libraries.

The non-vendor dependencies are the ones that tell you the shape of the tool. projectdiscovery/goflags is the flag library that produces that help output, gologger is the logging, and projectdiscovery/utils holds the shared helpers. golang.org/x/oauth2 is there for the credential flows, gopkg.in/yaml.v2 for the configuration files, and testify for the tests.

The module targets Go 1.26.0.

The design consequence of one SDK per provider is that adding a provider means adding a dependency, which is why the dependency list is long and why the DESIGN.md document exists. The alternative, querying each provider over plain HTTP, would keep the dependency tree small at the cost of reimplementing every provider's authentication and pagination, and the project has clearly chosen the SDKs.

Building it, the container image, and the release state

The build is a plain Go build with a static binary, and the Makefile shows the details.

build:
	$(GOBUILD) $(GOFLAGS) -ldflags '$(LDFLAGS)' -o "cloudlist" cmd/cloudlist/main.go

The linker flags are -s -w, and on anything that is not macOS the flags add -extldflags "-static", so the binary is static except on Darwin, where a static build is not the norm.

The Dockerfile is correspondingly small. It starts from alpine, upgrades the packages and installs bind-tools and ca-certificates, copies the platform-specific binary from a build artefact using the TARGETPLATFORM argument, and sets the entrypoint to cloudlist. The Go Report Card badge in the README points at the analysis of the same code.

The release story is the goreleaser configuration in .goreleaser.yml, and the project publishes binaries rather than requiring you to build from source.

The version history shows a project that is being maintained steadily. Version 1.3.0 came on 2026-01-21, 1.4.0 on 2026-02-09 and 1.5.0 on 2026-10-14, with the last push on the same day. The gaps are uneven, which fits a tool that gets a batch of provider work rather than a change every week, and the project is not archived.

The acknowledgements section credits Smogcloud and Cloudmapper as the inspirations, which is worth a mention because it places the tool in the lineage of cloud asset enumeration rather than in the lineage of vulnerability scanners.

Editorial conclusion

Adopt cloudlist if you need a running inventory of what you own in the cloud and you want it produced by one command rather than fifteen, especially if you already run ProjectDiscovery tooling. Do not adopt it as a compliance scanner, because it lists assets rather than checking them, and do not run it with credentials broader than the listing needs. Before you start, try the auto-discovery mode so the tool finds providers from the environment, check the GCP Asset API document if you want organisation-wide discovery rather than per-project listing, and keep the provider config file out of version control, since it holds the credentials for every provider you list.

Frequently asked questions

Official sources

1. License: MIT
2. projectdiscovery/cloudlist on GitHub
3. Project website
4. README
5. Releases