The gap between setting up SSO and having an access model
Single sign-on is a mechanism. It does not decide who should be allowed to do what. We often meet teams with a clean IAM Identity Center installation in which six people are administrators everywhere, because nobody wrote down who needed what and giving everyone admin was the quickest way to stop complaints.
Team onboarding is the human and process half of the ClickOps and cloud setup service. It turns the technology into a model that new starters, auditors and your future selves can understand, and it makes access something the company controls rather than something that accumulates.
What good looks like
- Anyone can see, on one page, who holds which rights in which account.
- A new engineer is productive on day one by being added to one or two groups.
- Production write access is rare, time-limited and logged.
- Leaving the company removes access automatically, the same day.
- Access reviews happen on a schedule and produce actual removals.
- Engineers know how to request more access and how long it takes.
Designing the access matrix
The matrix is a simple table. Rows are roles, columns are account types, and cells say what is granted. A realistic example:
| Role | Development | Staging | Production | Security and logging |
|---|---|---|---|---|
| Developer | Power user | Deploy via pipeline, read | Read-only, logs | None |
| Platform engineer | Admin | Admin | Admin, short session | Read |
| Security reviewer | Read | Read | Read | Admin |
| Finance or manager | Billing only | Billing only | Billing only | None |
| Contractor | Scoped, expiring | Scoped, expiring | None | None |
The values will differ for your business. What matters is that every cell is a decision, written down, and that the matrix matches how your account structure is laid out. Separate accounts make the matrix easy to enforce, because the boundary is the account itself.
Implementing it without per-person exceptions
Rights attach to groups, never to individuals. In the identity provider, each row in the matrix becomes a group. In Identity Center, each group is assigned a permission set in the relevant accounts. The only routine action then is changing group membership.
Exceptions will arise. We handle them with a short-lived, named assignment that has an expiry and a ticket reference, rather than a permanent personal grant. Permissions and assignments are kept in Terraform, so a change appears as a reviewed pull request, as covered in our Terraform landing zone work.
Requesting and approving access
Even small teams benefit from a simple, written flow:
- The engineer asks in a defined place (a ticket form or a chat workflow), stating the account, the role and the reason.
- A named approver for that environment says yes or no. Production approvals come from someone other than the requester.
- Access is granted with an end date, often a few hours to a few days.
- The grant and the reason are recorded.
Temporary elevation is a small cost for a large gain. When something goes wrong, the audit trail shows who did what and why, and the rights lapse automatically afterwards.
Joiners, movers and leavers
Joiners. A checklist adds the person to the identity provider, the correct role groups and the team channels. Credentials are never shared. The checklist includes setting up the CLI profile, which is where many teams lose a first day.
Movers. When someone changes team, old group memberships are removed as new ones are added. Without this step, long-serving employees become unintentionally powerful.
Leavers. Disabling the identity provider account ends cloud access. We also check for the things that survive it: IAM users, personal access keys, SSH keys on servers, shared secrets and tokens in third-party tools. Rotating anything the person could see is part of the checklist.
Contractors. They follow the same flows with expiry dates attached.
Teaching the team
A design that people do not understand gets bypassed. We run a practical session covering how to sign in with aws sso login, how to switch accounts, how to request elevated access, and what to do when something is denied. We also explain why: that the rules protect engineers as well as the company, because a narrower blast radius means fewer ways to cause a bad day by accident.
Reviewing access over time
Permissions drift upward. A scheduled review asks, for each privileged role: is everyone here still in the right job, and which granted permissions have not been used? IAM Access Analyzer and last-accessed data help find unused rights. The output is a short list of removals, agreed and actioned, not a report that gathers dust. For ongoing support with this, see our managed DevOps service.
Common failure modes
- Shared accounts. Several people using one login destroys accountability.
- Admin by default. Easy at first, impossible to reverse later.
- Orphaned access. Leavers’ personal keys and tokens remain active.
- Approval fatigue. If every request is slow, people find workarounds. Keep non-production self-service.
- Matrix drift. The document says one thing and the system another. Generating documentation from code prevents this.
When to keep it lighter
A three-person team with two accounts does not need an approval board. A one-page matrix, group-based access and a leaver checklist will cover most of the value. The model should grow with the company, and we say so plainly rather than selling process you will not use.
Delivery and handover
You receive the access matrix, the identity provider groups and permission sets in Terraform, the request and approval flow, joiner, mover and leaver checklists, and a recorded training session for future starters. To discuss how your team currently gets access, book a consultation.
How to tell it is working
- A new starter has the right access within a day without special requests.
- A leaver’s access disappears on their last day with nothing left over.
- Production write sessions are few, short and attributable.
- Review cycles end with removals, not just confirmations.