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

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.

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.

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.