Usage of localstack as a secrets source

So : I'm developing a CodeBuild job that's intended to run in a VPC because it needs access to network resources. I really need to make sure this works properly before I unleash it on the world and the servers in question are highly contended resources (even the dev ones), so I'm doing my best to simulate as much as possible as containers.

By mounting a new `docker-compose.yml` file over the top of the one inside the CodeBuild Local container as per [this comment](https://github.com/aws/aws-codebuild-docker-images/issues/326#issuecomment-2700702447), I can add services with healthchecks and dependencies to the stack - the agent doesn't start up until my target services are healthy.

Some of the parameters I need to feed to my job are secrets, but I don't have real ones available to me.

Aha! I thought, I'll use the same trick to put a `localstack` container in my service stack ... alas, this isn't going to work because environment variables are set by the `aws-codebuild-local` image ... and it doesn't seem to respect the `AWS_ENDPOINT_URL` variable when it makes requests to the Secrets Manager API.

What I'd like is to be able to configure a local build to use a local AWS API where appropriate.

---

Is this because /LocalBuild/agent-resources/executor is built against the v1 Go SDK[1], which as far as I can tell, doesn't use this environment variable as a configuration source[2]? Since the v1 Go SDK is due to be End-of-Life soon, will a port of the Go portions of the CodeBuild Local container to the v2 SDK be on the cards?

Going to have a try at configuring this another way[3] ... but the binary doesn't contain `endpoint_url` either so not sure it will respect the content of a config file.

[1] The binary contains the symbol string `CancelRotateSecretWithContext` which doesn't occur in the v2 SDK but does in v1
[2] Based on the string `AWS_ENDPOINT_URL` not occurring in the binary or in the sources of the v1 SDK
[3] Briefly, then I'll move to the more obvious workaround of setting up secrets with the same name[4] in an account I _do_ control
[4] Only I think I've seen an issue #312 where the local container requires ARNs rather than secret names so I can't really do a like-for-like test even then ...

Start by inspecting the /LocalBuild/agent-resources/executor entry point and the mounted docker-compose.yml setup described in the issue. Check how the local build agent configures Secrets Manager requests and whether AWS_ENDPOINT_URL or a config file is read. Done means a local build can direct the relevant AWS API calls to a local endpoint without requiring real secrets.

Written by the indexing model from the issue text.