Roll Out Vouch to Your Team

One-time admin setup, one enrollment command per developer

This page covers rolling Vouch out to a team: AWS, Kubernetes, and the package and repo services around them, with no static keys distributed at any point. Each step links to a deep-dive guide for details.

Day 0 – The foundation

Everything below hangs off one OIDC provider and one IAM role. The decisions in this section determine everything that follows.

1. Enroll yourself. Install the CLI and enroll your YubiKey – Getting Started (5 minutes). The first person to enroll from your Google Workspace domain becomes the organization owner.

2. Register the Vouch OIDC provider in AWS – one CLI command or one Terraform/CloudFormation resource. Exactly one per organization, in your management account if you have an AWS Organization. AWS guide, Step 1.

3. Pick your account layout. This decides what roles you deploy:

   Your AWS layout	What to deploy	Guide
   Single account	One VouchDeveloper role	AWS guide
   Multiple accounts (Organizations)	A hub role in the management account, a spoke role per account (StackSets or a Terraform module)	Multi-account
   IAM Identity Center already in place	Register Vouch as a trusted token issuer	Identity Center

4. Deploy the role(s) with the standard trust policy scoped to *@yourdomain.com. Start the permissions policy at ReadOnlyAccess and broaden deliberately. Write down the role ARN – it is the only thing developers need from you.

5. Plan user lifecycle. Under ~15 people, manual member management in the admin dashboard is fine. At 15+, connect SCIM so your IdP creates and deactivates Vouch users automatically.

Enable services

Each additional service is IAM permissions on the role you already deployed, plus at most one admin action. Developers then enable it with a single command. Full guides are linked for troubleshooting and edge cases.

Sequence tip: ship AWS first (everything else chains off it), then EKS and CodeCommit/CodeArtifact, then the rest as teams ask for them.

Onboard developers

Developers never touch IAM. Paste the block below into Slack or your onboarding wiki and fill in the two placeholders; each person completes setup on their own.

**Set up Vouch (one time, ~5 min, YubiKey required)**

1. Install the CLI and background agent:

       brew install vouch-sh/tap/vouch
       brew services start vouch

   (Linux/Windows: https://vouch.sh/docs/getting-started/)

2. Enroll your YubiKey -- opens the browser for SSO, then asks for a tap:

       vouch enroll --server https://us.vouch.sh

3. Connect AWS (paste the role ARN from your admin):

       vouch setup aws --role <ROLE_ARN>

4. Connect the cluster (if you use Kubernetes):

       vouch setup eks --cluster <CLUSTER_NAME>

5. Start each workday with one tap:

       vouch login

Check it worked: `aws sts get-caller-identity --profile vouch`
shows your email in the role ARN. Questions -> #devops-help

First-time enrollment needs no invite codes or approval – anyone authenticating through your Google Workspace domain lands in your organization automatically. (Enrolling an additional key later asks for a tap from the key already on file.)

Pilot, then roll out

Vouch installs alongside existing credentials – the vouch AWS profile, SSH certificates, and stacked Git credential helpers don’t disturb anything your team uses today. A staged rollout keeps existing credentials as a fallback:

1. Pilot on yourself plus one volunteer for a week, with static credentials still in place.
2. Migrate one integration at a time, AWS first. The migration guide has the recommended order, per-integration checklists, and a rollback plan for each integration.
3. Onboard the team with the block above once the pilot is clean.
4. Revoke static credentials last – deactivate old AWS access keys, remove stale authorized_keys entries and PATs only after everyone has run on Vouch for a week. Commands in migration, Phase 3.

CI/CD pipelines are a separate track: they have no YubiKeys and should use their platform’s own OIDC federation or instance roles, not Vouch. See CI/CD considerations – Vouch’s CI/CD integration adds human approval gates on top, it does not replace machine credentials.

When someone leaves

Because no static keys were distributed, offboarding is your identity provider plus, at most, one IAM statement.

1. Deactivate their account in your IdP (you were doing this anyway).
   • With SCIM: their Vouch sessions are revoked automatically the moment the IdP deactivates them. Nothing else to do on the Vouch side.
   • Without SCIM: use Deactivate and Revoke credentials in the admin dashboard.
2. Cut off cached AWS credentials (optional, for immediate effect): STS credentials already on their laptop live up to 1 hour. To kill them instantly, add the vouch:Email deny statement to your roles or as an SCP – copy it from Revoke access for a specific user.

What expires on its own:

There are no access keys, authorized_keys entries, or PATs to revoke. Full failure-mode detail (including break-glass access if the Vouch server is ever unreachable) is in Availability.

Related guides

• AWS Integration – the OIDC provider and role this whole page builds on.
• Multi-Account AWS – hub/spoke roles, StackSets, SCP guardrails.
• SCIM Provisioning – automatic user lifecycle from your IdP.
• Migration Guide – integration-by-integration checklists and rollback.
• Availability and Failure Modes – offline behavior and break-glass planning.