Usage of localstack as a secrets source

[awilkins]

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, 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 ...