HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
99designs
aws-vault
Go2015–2025
99designs / aws-vault

aws-vault

A vault for securely storing and accessing AWS credentials in development environments

24Distinct people
31Mentions
0Explicit recommenders
9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A vault for securely storing and accessing AWS credentials in development environments

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year31 dated mentions

Observed mentions: 2015-09-29 23:44:18 UTC to 2025-06-15 00:44:39 UTC.

02462015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC110
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC312
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC312
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
AWS Vault WarningThis project has been abandoned and it's not receiving any more updates. If you want to continue to receive updates or contribute, please feel free to look at the active fork at: https://github.com/ByteNess/aws-vault AWS Vault is a tool to securely store and access AWS credentials in a development environment. AWS Vault stores IAM credentials in your operating system's secure keystore and then generates temporary credentials from those to expose to your shell and applications. It's designed to be complementary to the AWS CLI tools, and is aware of your profiles and configuration in ~/.aws/config. Check out the announcement blog post for more details. Installing You can install AWS Vault: by downloading the latest release on macOS with Homebrew: brew install aws-vault on macOS with MacPorts: port install aws-vault on Windows with Chocolatey: choco install aws-vault on Windows with Scoop: scoop install aws-vault on Linux with Homebrew on Linux: brew install aws-vault on Arch Linux: pacman -S aws-vault on Gentoo Linux: emerge --ask app-admin/aws-vault (enable Guru first) on FreeBSD: pkg install aws-vault on OpenSUSE: enable devel:languages:go repo then zypper install aws-vault with Nix: nix-env -i aws-vault with asdf-vm: asdf plugin-add aws-vault https://github.com/karancode/asdf-aws-vault.git && asdf install aws-vault <version> Documentation Config, usage, tips and tricks are available in the USAGE.md file. Vaulting Backends The supported vaulting backends are: macOS Keychain Windows Credential Manager Secret Service (Gnome Keyring, KWallet) KWallet Pass Encrypted file Use the --backend flag or AWS_VAULT_BACKEND environment variable to specify. Quick start # Store AWS credentials for the "jonsmith" profile $ aws-vault add jonsmith Enter Access Key Id: ABDCDEFDASDASF Enter Secret Key: %%% # Execute a command (using temporary credentials) $ aws-vault exec jonsmith -- aws s3 ls bucket_1 bucket_2 # open a browser window and login to the AWS Console $ aws-vault login jonsmith # List credentials $ aws-vault list Profile Credentials Sessions ======= =========== ======== jonsmith jonsmith - # Start a subshell with temporary credentials $ aws-vault exec jonsmith Starting subshell /bin/zsh, use `exit` to exit the subshell $ aws s3 ls bucket_1 bucket_2 How it works aws-vault uses Amazon's STS service to generate temporary credentials via the GetSessionToken or AssumeRole API calls. These expire in a short period of time, so the risk of leaking credentials is reduced. AWS Vault then exposes the temporary credentials to the sub-process in one of two ways Environment variables are written to the sub-process. Notice in the below example how the AWS credentials get written out $ aws-vault exec jonsmith -- env | grep AWS AWS_VAULT=jonsmith AWS_DEFAULT_REGION=us-east-1 AWS_REGION=us-east-1 AWS_ACCESS_KEY_ID=%%% AWS_SECRET_ACCESS_KEY=%%% AWS_SESSION_TOKEN=%%% AWS_CREDENTIAL_EXPIRATION=2020-04-16T11:16:27Z Local metadata server is started. This approach has the advantage that anything that uses Amazon's SDKs will automatically refresh credentials as needed, so session times can be as short as possible. $ aws-vault exec --server jonsmith -- env | grep AWS AWS_VAULT=jonsmith AWS_DEFAULT_REGION=us-east-1 AWS_REGION=us-east-1 AWS_CONTAINER_CREDENTIALS_FULL_URI=%%% AWS_CONTAINER_AUTHORIZATION_TOKEN=%%% The default is to use environment variables, but you can opt-in to the local instance metadata server with the --server flag on the exec command. Roles and MFA Best-practice is to create Roles to delegate permissions. For security, you should also require that users provide a one-time key generated from a multi-factor authentication (MFA) device. First you'll need to create the users and roles in IAM, as well as setup an MFA device. You can then set up IAM roles to enforce MFA. Here's an example configuration using roles and MFA: [default] region = us-east-1 [profile jonsmith] mfa_serial = arn:aws:iam::111111111111:mfa/jonsmith [profile foo-readonly] source_profile = jonsmith role_arn = arn:aws:iam::22222222222:role/ReadOnly [profile foo-admin] source_profile = jonsmith role_arn = arn:aws:iam::22222222222:role/Administrator mfa_serial = arn:aws:iam::111111111111:mfa/jonsmith [profile bar-role1] source_profile = jonsmith role_arn = arn:aws:iam::333333333333:role/Role1 mfa_serial = arn:aws:iam::111111111111:mfa/jonsmith [profile bar-role2] source_profile = bar-role1 role_arn = arn:aws:iam::333333333333:role/Role2 mfa_serial = arn:aws:iam::111111111111:mfa/jonsmith Here's what you can expect from aws-vault Command Credentials Cached MFA aws-vault exec jonsmith --no-session Long-term credentials No No aws-vault exec jonsmith session-token session-token Yes aws-vault exec foo-readonly role No No aws-vault exec foo-admin session-token + role session-token Yes aws-vault exec foo-admin --duration=2h role role Yes aws-vault exec bar-role2 session-token + role + role session-token Yes aws-vault exec bar-role2 --no-session role + role role Yes Development The macOS release builds are code-signed to avoid extra prompts in Keychain. You can verify this with: $ codesign --verify --verbose $(which aws-vault) If you are developing or compiling the aws-vault binary yourself, you can generate a self-signed certificate by accessing Keychain Access > Certificate Assistant > Create Certificate -> Certificate Type: Code Signing. You can then sign your binary with: $ go build . $ codesign --sign <Name of certificate created above> ./aws-vault References and Inspiration https://github.com/pda/aws-keychain https://docs.aws.amazon.com/IAM/latest/UserGuide/MFAProtectedAPI.html https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html#create-iam-users https://github.com/makethunder/awsudo https://github.com/AdRoll/hologram https://github.com/realestate-com-au/credulous https://gith
Read the full README on GitHub

What Hacker News says

7 sources
mostly copy-pasta from an earlier comment[0] of mine: https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only months ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more. I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both. I appreciate that Boundary gives completely generic identity-aware-authenticated TCP sockets, but I don't know of a way, today, to make those not accessible to browsers through dns rebinding attacks. This is
Read the rest
probably much much too far in the weeds and this is unlikely to contribute to a major breach (unlike the aws-vault one where of course attackers would try to access the fake metadata service on the default port, because it's high-value and on a well-known port), but I'm interested in the space. [0] https://news.ycombinator.com/item?id=23265509 [1] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...
In HashiCorp Boundary
Or OIDC, if SAML gives one a rash: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr... The aws-vault project recently added support for AssumeRoleWithWebIdentity making it cheap to issue yourself disposable credentials: https://github.com/99designs/aws-vault/blob/v6.0.0-beta9/USA... including launching AWS Console links for those Roles: https://github.com/99designs/aws-vault/blob/v6.0.0-beta9/USA... Kind of speaking to the blog post's intention, I actually don't have any IAM Users in my AWS account
In How to give access to AWS resources without creating 100s of IAM Users?
Another nice thing about env vars is that they don't appear in the process table, unlike argv. For many applications, that makes them a suitable place to inject secrets, and makes them convenient to inject via wrapper tools. For instance, the fact that the aws(1) cli tool and the AWS SDKs by default take IAM creds from AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc. means that you can write programs like aws-vault (https://github.com/99designs/aws-vault) which can acquire a temporary AWS session and then execute another command with the creds injected in the standard AWS_... env vars. For instance: aws-vault exec prod-read -- aws s3 ls aws-vault exec stage-admin -- ./my-script-that-uses-the-aws-sdk-internally Also, passing arguments as env vars is part of the "12-factor app" design (https://12factor.net/config). That page has some
Read the rest
good guidance.
In Conventions for Command Line Options
> Is there a way to use SSM without using the access keys? I feel using access keys is incredibly not secure because rotating keys is a hassle and people might not do them all the time. Technically there is, you can use federated login. Might not be very convenient, depending on your identity provider. A solution I use, while not technically "not using access kys" is storing them in the system credential store with aws-vault [0]. Works on Windows, Linux and Mac. And you can combine this with multi factor auth. > Also can u restrict access to ssh through ssm to certain ips? Yes, with an IAM policy. The policy below requires connecting with an MFA and from a specific IP range. It only allows connecting to a specific instance. { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow
Read the rest
", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ec2:eu-west-3:123123123123:instance/i-123123123123", "arn:aws:ssm:eu-west-3::document/AWS-StartPortForwardingSession", "arn:aws:ssm:eu-west-3::document/AWS-StartSSHSession" ], "Condition": { "IpAddress": { "aws:SourceIp": "1.2.3.4/32" }, "BoolIfExists": { "aws:MultiFactorAuthPresent": "true" } } } ] } [0] AWS Vault: https://github.com/99designs/aws-vault/
In Bastions on demand in an AWS VPC
> that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials. In terms of local development experience, most mature organizations will have these "long lived" credentials still require an MFA at a minimum of once per day and locked down to particular IP addresses to be allowed to get the temporary credentials.[1] > This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances. Typically you'd want to see third-party platforms leveraging IAM cross-account roles these days to fix the problem of them having static credentials. Granted, many of them are still using AWS access key and secret. This is still not a "solved" area though, and a point of concern I wish would get more aggressively addressed by AWS. [1] https://github.com/trek10inc/awsume, ht
Read the rest
tps://github.com/99designs/aws-vault, and a few other tools make this much easier to deal with locally.
In AWS CodeArtifact: A fully managed software artifact repository service
If you want to log in to multiple AWS accounts, the best solution I have found is a thin shell script wrapper around `aws-vault login` [0] that opens Chrome with a dedicated profile. aws-vault stores an API key in your local keychain, fetches a temporary session key on demand, and logs you in automatically. I've put the shell script I use here: https://gitlab.com/snippets/1979112 You should be able to adapt it to Firefox pretty easily. [0] https://github.com/99designs/aws-vault
In Firefox extensions to make remote work and school a little better
I agree about it being scary that the browser doesn't do more to prevent connections from from "localhost" to "not localhost". https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only a couple weeks ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more. I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both. [0] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...
In Stealing secrets from developers using WebSockets

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.