Roll Out Vouch to Your Team

One admin afternoon, one command per developer, no blockers

Your job: get everyone on the team into AWS, Kubernetes, and the package and repo services around them — fast, without handing out static keys, and without you becoming the person everyone waits on. This page is the whole playbook. Each step links to a deep-dive guide, but you should rarely need one.

Day 0 – The foundation

Everything below hangs off one OIDC provider and one IAM role. This is the only part with real decisions in it.

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 a few lines of Terraform/CloudFormation. 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 when something goes sideways.

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, fill in the two placeholders, and each person is productive in about five minutes – no action from you.

**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

Enrollment needs no invite codes or approval – anyone authenticating through your Google Workspace domain lands in your organization automatically.

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. So de-risk the rollout the boring way:

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

This is the payoff for never distributing static keys: 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 to hunt down, no authorized_keys to scrub, no 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.