AWS and Kubernetes

shortspan aws production

Spawns a subshell with AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION set from the registered profile. The AWS CLI, Terraform, the SDKs, and anything else that reads the standard variables work inside it with no further setup. Type exit and the credentials are gone with the shell.

Nothing is written to ~/.aws/credentials. That file is the usual way a long-lived access key ends up outliving the reason it existed.

One command instead of a shell

shortspan aws production --exec "aws s3 ls s3://backups"
shortspan aws production --exec "terraform plan"

Runs a single command with the credentials injected and exits. This is the form to use in scripts and CI - a subshell needs a TTY.

shortspan k8s prod-cluster

Fetches the registered kubeconfig and spawns a subshell with KUBECONFIG pointed at it. kubectl, helm, k9s, and anything else that honours the variable use it. Your own ~/.kube/config is untouched, so this cannot leave you accidentally pointed at production afterwards.

Both are registered in the console under Infrastructure.

AWS profile

An alias, an access key id, a secret access key, and a default region. The secret key is encrypted at rest and never displayed again.

Kubernetes context

An alias, the cluster name, and the kubeconfig document. The whole document is encrypted, since it usually contains a client certificate or a token.

Update the profile in the console with the new key. The next shortspan aws picks it up - there is nothing cached on any machine to invalidate, which is most of the value of not distributing credentials in the first place.

Deactivate the old key at AWS afterwards, not before, and check the audit log for anything still requesting the profile if you are unsure whether something depends on it.