splunk / splunk/attack_range

Government clouds are not currently supported

Open
#1,415 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
2.6k
Forks
417
PR merge metrics
No merged PRs in 30d

Description

The cloud providers in the attack range templates default to the commercial endpoints for AWS/GCP, and there is currently not an option to specify Azure Government/AWS GovCloud.

Diagnosis

  1. Azure authentication authority defaults to commercial Entra ID

In attack_range/cloud_providers/azure_provider.py, every client uses:

DefaultAzureCredential()

No sovereign authority is specified, so environment-based credentials default to the public-cloud authority rather than login.microsoftonline.us.

Microsoft’s Python guidance requires AzureAuthorityHosts.AZURE_GOVERNMENT for Azure Government.

  1. Azure management clients default to public ARM

The code constructs ResourceManagementClient and StorageManagementClient without either:

base_url="https://management.usgovcloudapi.net"
credential_scopes=["https://management.usgovcloudapi.net/.default"]

Therefore, they communicate with management.azure.com. Microsoft notes that sovereign-cloud clients need both the correct authority and the appropriate management endpoint/scope.

This produces errors such as:

  • SubscriptionNotFound
  • InvalidAuthenticationTokenAudience
  • Authentication succeeding but the subscription not existing in the selected cloud
  • Requests unexpectedly going to management.azure.com
  1. Blob Storage is explicitly hard-coded to commercial Azure

These two locations are unequivocal:

account_url=f"https://{account_name}.blob.core.windows.net"

They appear in both check_storage_container() and create_storage_container().

Azure Government Blob Storage uses:

<account>.blob.core.usgovcloudapi.net

Microsoft’s Azure Government Storage documentation confirms that endpoint and shows it paired with the Government authority.

This means there is no complete environment-variable-only workaround for the current source. Even after fixing authentication and ARM settings, backend-container creation still contacts public Blob Storage.

  1. The Terraform Azure provider defaults to public

Current terraform/azure/main.tf:

provider "azurerm" {
  features {}
  subscription_id = var.azure.subscription_id
}

It has no:

environment = "usgovernment"

The AzureRM provider supports usgovernment, but defaults to public when it is omitted.

  1. The Terraform state backend separately defaults to public

The generated backend "azurerm" block also lacks an environment:

backend "azurerm" {
  resource_group_name  = "..."
  storage_account_name = "..."
  container_name       = "tfstate"
  key                  = "terraform.tfstate"
}

Terraform’s AzureRM backend has its own environment setting and independently defaults to public. It also recognizes ARM_ENVIRONMENT=usgovernment.

The provider and backend must both target Azure Government; fixing only one is insufficient.

  1. The application UI cannot describe Azure Government

api/cloud_fields.py has:

  • No Azure environment selector
  • No Azure Government locations
  • Only commercial locations such as East US, West Europe, and Central US

So the generated configuration cannot distinguish between:

azure:
  environment: public

and:

azure:
  environment: usgovernment

AWS GovCloud is different

The AWS runtime implementation is largely partition-compatible already:

boto3.client("s3", region_name=region)
boto3.client("ec2", region_name=region)

and:

provider "aws" {
  region = var.aws.region
}

Boto3 recognizes aws-us-gov as a distinct partition, and AWS identifies us-gov-east-1 and us-gov-west-1 as the GovCloud region names.

The main AWS problem is that the UI’s fixed region list excludes both GovCloud regions. Unlike Azure, there did not seem to be any commercial API endpoints hard-coded in the AWS backend/provider implementation.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with attack_range/cloud_providers/azure_provider.py, terraform/azure/main.tf, and api/cloud_fields.py, then trace how generated Terraform backend settings and cloud locations are assembled. Verify the Azure environment, authority, management, storage, provider, and backend settings stay consistent, and that the UI also exposes Azure Government and AWS GovCloud regions.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, azure, python, terraform
Domain
backend, cloud, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.