New post: The death of the long-lived cloud credential. Long-lived access keys are the COBOL of cloud auth — predate the tools that replaced them, survive on inertia. A specific 2030 prediction inside. credctl.com/blog/death-o...
Credctl.com
@credctl.com
credctl uses your laptop's Secure Enclave to create hardware-bound device identities that replace long-lived cloud access keys with short-lived credentials. No plaintext keys on disk. Ever. https://credctl.com
New post: credctl vs Granted — workflow ergonomics vs hardware identity. Granted's browser-profile console UX is genuinely great. credctl's hardware identity solves a different problem. They compose well. credctl.com/blog/credctl...
Wrote up how the Secure Enclave handles AWS auth: cgo to Apple's Security framework, ECDSA P-256 in hardware, OIDC federation, Touch ID per signing. CFDictionary lifecycle was the most painful part. credctl.com/blog/secure-...
New post: credctl vs HashiCorp Vault — not a replacement. Vault is a centralised secrets manager. credctl handles laptop-to-cloud auth via hardware-bound keys. You can chain them via Vault's JWT auth method. credctl.com/blog/credctl...
Working on the team-broker design for credctl. Single-developer use is solved — install CLI, federate, done. Harder problem: a team with policy ("only seniors can assume prod"), audit (who assumed what when), and device fleet management. Most-asked-for feature so far.
A design choice that surprised me: AWS, GCP, and Azure all converged on accepting the same OIDC token format. Same JWT, same claims, same JWKS discovery. Different APIs, same wire protocol. One identity, three clouds. The federation interop story is genuinely good.
New post: credctl vs aws-vault — when to use each. Honest comparison, including where aws-vault is the better choice (Linux/Windows, AWS SSO, existing setups). Same goal, different security model. credctl.com/blog/credctl...
Spending evenings on TPM 2.0 integration for Linux. Same architecture as Secure Enclave on macOS — generate a non-extractable signing key, sign JWTs, federate to AWS. cgo equivalent: tpm2-tss bindings. Different chip family, same shape of problem.
aws-vault solved the plaintext-keys problem in 2014 by encrypting them in the OS keychain. Real improvement — orders of magnitude better than ~/.aws/credentials. Hardware-bound credentials go one step further: the long-lived material lives in a chip that can't export it.
SPIFFE works great in Kubernetes. Pods get short-lived JWTs from the cluster's signer, federate to the cloud, never see a long-lived credential. Then you hit a dev laptop with a long-lived IAM key in ~/.aws/credentials. Same person, totally different security posture.
Vercel breach in one line: bearer secrets work from anywhere — which is why "rotate everything" is the only safe response after a platform breach. If they weren't bearer secrets, there'd be nothing to rotate. credctl.com/blog/vercel-...
Unpopular opinion: "just rotate your AWS keys regularly" is not a security strategy. Between rotations, those keys are still in plaintext on disk. Rotation reduces the blast radius window. It doesn't eliminate the attack surface. The real fix is not having long-lived keys at all.
Working on multi-cloud credential management. One thing I didn't expect: AWS Roles Anywhere, GCP Workload Identity Federation, and Azure Federated Identity Credentials all accept the same OIDC token format. Different APIs, same underlying pattern. One identity provider can serve all three.
Interesting design pattern: OIDC federation lets any service that can produce a signed JWT get short-lived cloud credentials. AWS, GCP, and Azure all support it. Your CI runner uses it. Your Kubernetes pods use it. Your laptop could too — if something signed the JWT with a hardware-bound key.
The CircleCI breach (2023): malware on a dev laptop stole a session cookie. The LastPass breach (2022): a dev workstation was compromised. Both started the same way — credentials accessible on a dev machine. We keep building more sophisticated auth systems while leaving plaintext keys on disk.
Writing Go for the macOS Secure Enclave means cgo + Apple's Security framework. SecKeyCreateRandomKey to generate keys. SecKeyCreateSignature to sign. The private key never touches Go memory — the Enclave does the crypto internally. Getting the CFDictionary bridging right was... an experience.
TIL you can set up your own OIDC identity provider for AWS with just two static JSON files on S3 + CloudFront. openid-configuration + a JWKS document. That's it. AWS STS will validate your JWTs against it via AssumeRoleWithWebIdentity. No Cognito, no Auth0, no server.
86% of breaches involve stolen credentials (Verizon DBIR). Most developer laptops have AWS keys sitting in ~/.aws/credentials in plaintext. Meanwhile every Mac since 2016 has a Secure Enclave — a chip that makes keys that physically can't be extracted. The gap between those two facts is wild.
Building credctl — an open-source CLI that replaces the plaintext AWS/GCP keys on your laptop with Secure Enclave-bound credentials. Touch ID instead of ~/.aws/credentials. github.com/credctl/credctl
GitHub - credctl/credctl: Manage credentials with machine identity
Manage credentials with machine identity. Contribute to credctl/credctl development by creating an account on GitHub.
github.com