You know that sinking feeling when a switch or automation script needs credentials, and no one quite remembers where they live? Then there’s the Slack message: “Who can give me access?” Ten minutes gone, confidence shaken. That problem is exactly what the combination of Arista and HashiCorp Vault fixes when set up right.
Arista provides the fabric, the switches, and the programmable network under your apps. HashiCorp Vault manages secrets, tokens, and keys that let systems talk without spilling credentials in logs or configs. Together they make networks and secret management act like one system that already knows who’s allowed and who isn’t.
At the heart of it is identity mapping. Arista CloudVision, with its automation APIs, can request credentials dynamically from Vault through OIDC or token-based authentication. Instead of storing static passwords, you let Vault issue short-lived secrets. CloudVision or EOS devices pull them only when needed. The result is a network with real-time trust boundaries instead of static access lists.
A tidy workflow looks like this:
- Arista’s automation service initiates a job that needs device credentials.
- The request hits Vault’s policy engine, which checks identity via Okta or AWS IAM.
- Vault issues a temporary credential scoped specifically for that task.
- Arista executes it, logs the action, and discards the token.
No sticky notes, no long-term secrets.
If something misbehaves, the logs in both Vault and Arista tell a full story. Troubleshooting becomes about verifying intent, not hunting ghosts. Rotate the trusted identities regularly and keep policies short. Vault’s policy language is your friend when expressing fine-grained permissions like “network/regionX/read-only.”