[Feature] Support monitoring multiple cloud accounts per provider

[EvanMcBroom]

Feature Description

Support for configuring and monitoring multiple cloud accounts across supported providers.

Are you intending to implement this feature?

No.

Current Behavior

Cloud monitoring is currently configured through a singleton CloudServicesConfiguration model. That model stores one AWS access key, one AWS secret, and one DigitalOcean API key, plus shared settings such as ignore tags and notification delay.

The review_cloud_infrastructure task reads only that singleton configuration with CloudServicesConfiguration.get_solo(). It then:

• tests one AWS credential pair
• fetches EC2, Lightsail, and S3 assets using that same AWS credential pair
• fetches DigitalOcean droplets using one API token
• stores discovered assets in vps_info["instances"] keyed by the raw resource ID

Because the credentials are singleton fields, there is no supported way to monitor multiple AWS accounts or multiple DigitalOcean accounts without rotating credentials or running separate Ghostwriter instances. Azure monitoring is also not currently implemented; the docs state the cloud task is under development for Microsoft Azure support.

The management page and credential test actions are also hardwired to the singleton model, so the UI can only show and test one AWS key pair and one DigitalOcean token.

Desired Behavior

Ghostwriter should allow users to define any number of enabled cloud accounts and include all enabled accounts in cloud monitoring.

Use Case

Monitoring more than one account per provider, for example:

• 2 AWS accounts
• 2 DigitalOcean accounts
• 2 Azure subscriptions/tenants

Teams may require splitting infra across accounts for client/op separation, billing, least privilege, or provider-specific workflows.
This would make cloud teardown and untracked asset notifications usable for such teams.

Implementation Suggestions

Model changes:

• Keep global cloud monitoring settings, such as enable, ignore_tag, and notification_delay, in a global configuration model.
• Add a related model such as CloudServiceAccount or CloudAccountConfiguration which includes:
  • display name/account label
  • provider enum, for example aws, digital_ocean, azure
  • enabled flag
  • provider-specific credential fields or a provider-specific encrypted/config JSON structure
  • optional account/subscription identifier if it can be discovered or supplied
  • created/updated timestamps

Task changes:

• Change review_cloud_infrastructure to query all enabled cloud accounts when cloud monitoring is enabled.
• For each account, call provider-specific fetch/test logic with that account's credentials.
• Normalize fetched assets with provider, account label, and account ID/subscription ID.
• Store discovered assets in a list or under a composite key such as {provider}:{account_id_or_config_id}:{resource_id} rather than only instance["id"].
• Namespace errors by account, for example errors["aws"]["red-team-prod"] or errors[account.pk].
• Continue processing other accounts if one account fails authentication or an API call.

Provider changes:

• Update ghostwriter.modules.cloud_monitors so provider functions can return account-aware asset records
• Add Azure monitor support in a provider module or behind the same provider interface. At minimum, support listing Azure VM instances with public/private IPs, state, tags, region, and launch/create time where available.

UI/admin changes:

• Replace the single AWS/DigitalOcean credential fields in the cloud configuration admin with an account list or inline account editor.
• Add per-account test buttons for AWS, DigitalOcean, and Azure.
• Update the management page to show configured cloud accounts by label/provider with sanitized credential summaries instead of only one AWS key and one DigitalOcean key.

Migration/backwards compatibility:

• Avoid requiring users to re-enter existing credentials during upgrade.

Additional Information

The current task stores discovered resources by raw instance/bucket/droplet ID. With multiple accounts, resource IDs can collide across providers or accounts, so the implementation should use account-aware keys or a list-based result structure.