aws-login-proxy

A local credentials proxy that makes the AWS CLI's aws login feature (console-session-based local auth, no long-term IAM keys) actually reliable for day-to-day use — including inside Docker containers — without creating any IAM role, without storing a static access key anywhere, and without touching your AWS account at all.

The problem this solves

aws login is great in theory: it opens a browser, ties your CLI/SDK access to your existing AWS Console session, and never writes a long-term access key to disk. In practice, the credential it hands you is short-lived (observed ~10–15 minutes, not the hours-long console session itself), and the silent background refresh that's supposed to keep it alive is a single unretried network call. When that call has a bad moment — and it does, regularly — every tool relying on it (the AWS CLI, SDKs, IDE extensions) fails with something like:

CredentialsProviderError: Could not load credentials from any providers

...and the only fix is re-running aws login by hand. This is especially bad for Docker: containers don't have your aws login session at all, so there's no way to hand them working credentials without either baking in a long-lived access key (exactly what aws login was meant to avoid) or creating IAM infrastructure just to get a longer-lived session.

The fix

aws-cred-proxy is a small background daemon that:

1. Wraps the AWS CLI's own credential resolution (aws configure export-credentials, which already knows how to read your aws login session) with retries and backoff, absorbing the transient failures that otherwise bubble straight up to you.
2. Proactively refreshes in the background on a timer, so nothing is ever caught making a live network call under time pressure.
3. Serves the current credential over AWS's own container credentials protocol (AWS_CONTAINER_CREDENTIALS_FULL_URI / AWS_CONTAINER_AUTHORIZATION_TOKEN) — the same mechanism ECS and EKS use. Every AWS SDK in every language already supports this natively, so containers need zero awareness of aws login, DPoP, or OAuth2 refresh.
4. Runs as a background service (launchd on macOS, systemd --user on Linux) that starts at login and restarts itself if it ever dies.

Because the proxy reads and writes the same on-disk token cache that the AWS CLI and AWS SDKs use for login_session, keeping it warm here also tends to fix the flakiness for every other tool on your machine that relies on the same session — not just Docker.

No IAM role. No access keys. No changes to your AWS account. Just a more patient, retrying version of the credential resolution you already have.

Requirements

• macOS or Linux
• AWS CLI v2 with aws login support (v2.36+)
• Python 3 (stdlib only, no pip packages)
• Docker (or an OrbStack/Docker Desktop-compatible runtime) with --network host support, if you want the Docker integration

Install

git clone https://github.com/mihirgupta0900/aws-login-proxy.git
cd aws-login-proxy
./install.sh

This copies the scripts to ~/.local/bin and starts the background service.

Usage

# One-time, whenever your browser console session itself has expired:
aws login

# Check the proxy is up and serving valid credentials:
aws-cred-proxy-ctl status

# Run any container with working AWS credentials:
docker-aws-run --rm amazon/aws-cli sts get-caller-identity

# Or use it as a drop-in for your own images:
docker-aws-run --rm -v "$PWD":/app my-image:latest python script.py

aws-cred-proxy-ctl subcommands: start, stop, restart, status, logs [n].

Using it as a fallback profile for other tools

aws configure export-credentials (which the proxy already depends on) can also be pointed at directly by any tool that supports credential_process, if you'd rather not go through Docker at all:

# ~/.aws/config
[profile stable]
credential_process = aws configure export-credentials --profile default

How it works

 aws login (browser)
        |
        v
 ~/.aws/login/cache/*.json   <-- short-lived token + refresh token
        |
        | read/refresh with retries, every ~30s if <5 min remain
        v
 aws-cred-proxy (background daemon, 127.0.0.1:8081)
        |
        | AWS_CONTAINER_CREDENTIALS_FULL_URI=http://127.0.0.1:8081/creds
        | AWS_CONTAINER_AUTHORIZATION_TOKEN=<random token>
        v
 docker run --network host ...

--network host is required because AWS's HTTP credential provider deliberately only trusts loopback addresses or HTTPS for AWS_CONTAINER_CREDENTIALS_FULL_URI (this is a real security check in the SDK, not a limitation of this project) — so the container needs to actually be on the host's network to reach 127.0.0.1.

Security notes

• The proxy binds to 127.0.0.1 only — it is not reachable from your network or from other machines.
• A random bearer token (~/.aws/docker-cred-proxy-token, generated on first run, chmod 600) is required on every request, so other local processes can't silently read your credentials off the port.
• Credentials served are always short-lived, temporary session credentials (same as aws login itself provides) — never long-term access keys.
• --network host means the container shares your host's network stack. Don't combine this with untrusted container images.

Uninstall

./uninstall.sh

Stops the background service and removes installed files and local state. Does not touch your AWS account or your aws login session.

License

MIT