Command line tools keep credentials in a mix of plain files in your home directory and operating system credential stores. The AWS CLI uses plaintext config and credentials files, the GitHub CLI prefers a credential store but can fall back to a plain text file, and Docker falls back to a base64 encoded config.json when no store is set.
Why this belongs in a tooling post
Any program you run as yourself can read files in your home directory. That includes a poisoned editor extension, a malicious package install script, or a compromised global tool. So the question "what is lying around in my home folder" is the same question as "what would an attacker get if one tool on this laptop went bad". Our post on what to rotate after each attack class starts from the same idea.
Four tools, four behaviours
| Tool | Where credentials live, per its documentation | Notes |
|---|---|---|
| AWS CLI | config and credentials files, described as plaintext files; SSO tokens cached under ~/.aws/sso/cache | Short-term credentials can appear in the credentials file |
| GitHub CLI | system credential store after browser login; falls back to a plain text file if no store is found | gh auth status shows the stored location |
| Docker | the configured credential store; Docker Desktop uses the OS keychain | Without a store, config.json holds base64 encoded credentials, which Docker calls less secure |
| kubectl | default kubeconfig at $HOME/.kube/config, or files listed in KUBECONFIG | kubectl config view shows the merged result |
Each of these facts comes from the tool's own documentation, listed below. Behaviour can change between versions, so confirm on your own machine.
How to review your own laptop
- Open the AWS config and credentials files and look for long-lived access keys. Prefer short-lived sign-in methods where your organisation supports them.
- Run gh auth status and note where the token is kept. If it says a plain text file, consider fixing the credential store.
- Open the Docker config.json. If it holds an auth entry, set up a credential store or helper.
- Run kubectl config view and delete contexts for clusters you no longer use.
- Look for tokens in shell profile files and project env files. Our post on how developers get secrets on laptops lists safer patterns.
What a good state looks like
- Few long-lived credentials, each with the narrowest scope that does the job.
- Credential stores in use, not plain files, wherever the tool supports it.
- Nothing for projects you finished last year.
- A written list of where each credential came from, so rotation is possible.
When a tool goes bad
If you install something that turns out to be malicious, assume what the account could read, was read. Rotate those credentials from a clean device, starting with the most powerful. A short inventory made now saves hours later.
Quick check
Is a base64 encoded credential encrypted?
No. Base64 is an encoding, not encryption. Docker's own documentation calls the config.json method less secure than a credential store.
How do I find where the GitHub CLI keeps its token?
Run gh auth status, which the documentation says shows the stored location.
Sources
- AWS CLI configuration and credential files
- GitHub CLI gh auth login manual
- docker login reference
- Kubernetes kubeconfig documentation
Last reviewed: 19 October 2026.
