Managing Cloud Account Access Across a Team
Shared logins work until the team grows or someone leaves. What to put in place before that, and how to keep it from decaying.
The first version of access management is always one login shared by whoever
needs it. It works, which is why it persists, and it fails in three predictable
ways: nobody can tell who did something, removing one person means changing the
password for everyone, and the password ends up in a chat message that outlives
the project.
One identity per person
This is the change that makes everything else possible. Every person gets
their own user, with their own credentials and their own second factor.
The benefits are immediate. Audit logs become meaningful, because actions
attach to a person. Offboarding becomes disabling one account rather than
rotating a shared secret. And permissions can differ, which is the next
point.
Providers vary in how far they support this. The large platforms offer
detailed identity and access management; smaller ones often have a simpler team
model with a handful of roles. A simpler model is usually sufficient for a small
team and considerably easier to keep correct, which is a genuine advantage
rather than a limitation.
Grant what the job needs
Least privilege is a simple idea that decays under pressure. Someone needs
access urgently, they are granted broad permissions to unblock them, and nobody
narrows it afterwards.
Two habits keep it honest. Start from a role rather than from a person: define
what a developer, a contractor or a monitoring integration needs, and assign
people to those definitions. And when you grant something temporarily, write
down when it should be removed, because otherwise temporary means permanent.
Pay particular attention to who can do the irreversible things: deleting
resources, changing billing, modifying access for others, and altering
logging.
Separate environments properly
Production and non-production should be separated by something stronger than
discipline. On platforms that support multiple accounts or projects, use them.
The gap between staging and production should be a boundary, not a naming
convention and a hope.
Most people need routine access to non-production and occasional, deliberate
access to production. Making production access a conscious step rather than the
default prevents a large share of accidents.
Service credentials are the bigger risk
Human access gets the attention; machine credentials cause more incidents.
Deployment pipelines, monitoring agents and applications all need to
authenticate, and their credentials are long-lived, often broadly scoped, and
stored in places that leak.
- Prefer the platform’s own workload identity or instance role mechanism over
static keys. A credential that does not exist cannot leak. - Where a static key is unavoidable, give each integration its own, scoped
narrowly, so one can be revoked without breaking the others. - Keep them in a secrets manager rather than in environment files committed
alongside the code. - Rotate on a schedule and immediately on any doubt.
This connects to securing a new
cloud account, where key handling is covered in more detail.
Offboarding, properly
When someone leaves, a checklist beats memory:
- Disable their user on every cloud account, not just the main one.
- Remove their SSH public keys from servers and from the provider account.
- Rotate any shared credential they knew, including anything in a shared
vault. - Rotate API keys they created or had access to.
- Check whether anything is registered to their email address or their phone
number for recovery. - Confirm they were not the sole holder of anything, which is the discovery
that turns a routine departure into a problem.
That last item is the reason to review ownership periodically rather than at
the point of departure. See
why account ownership matters.
Review it on a schedule
Access lists only grow. Twice a year, read through who has access to what and
remove anything you cannot justify. It takes an hour and it is the only thing
that stops gradual accumulation.
Pay specific attention to accounts belonging to people who have changed
roles, integrations with services you stopped using, and API keys whose purpose
nobody can identify. An unexplained key is not a mystery to be tolerated; it is
a credential to be revoked.
The smallest workable setup
For a team of two or three, this does not need to be elaborate:
- Individual logins with multi-factor authentication, no shared password.
- A shared password manager for the few genuinely shared secrets, including
the root credentials and recovery codes. - Separate staging and production.
- Per-integration API keys in a secrets store.
- A written offboarding checklist.
That is an afternoon of work, and it covers the realistic risks for a small
team far better than a sophisticated policy framework nobody maintains.