Stop Sharing One Cloud Account: A Practical IAM Guide

If everyone on your team logs in to the cloud console with the same account and password — or if every new hire is handed full administrator rights “just to get unblocked” — you’ve seen the two most common identity mistakes in cloud computing. Both end the same way: when something breaks at 2 a.m., nobody can answer the question “who changed that?”

Huawei Cloud’s answer is IAM — Identity and Access Management. It’s the service that lets your one paying account create sub-identities, organize them into groups, and give each group exactly the permissions it needs. It’s also a free service, so there’s genuinely no reason to skip it.

One account, many users: the mental model

Think of it like this. Your Huawei Cloud account is the owner of everything: it owns the resources, it pays the bills, and it can’t be modified or deleted from inside IAM (account-level changes live under “My Account”). From that account, you create IAM users — one per person, or one per application.

The relationship is parent-child. The account owns the resources and pays for whatever its IAM users consume. And here’s a detail straight from the official documentation that’s easy to miss: IAM users cannot pay bills themselves. All spending rolls up to the account. That single fact shapes how you should think about cost accountability — track it by project or by tag, not by user, because the invoice never splits by user.

Start with groups, not users

The single biggest time-saver in IAM: don’t attach permissions to individual users. Create user groups first, attach permissions to the groups, then put users in groups.

There’s a built-in group called admin that holds full permissions over every service, including IAM itself. Treat membership in it like handing someone the master key — reserve it for the one or two people who genuinely need to manage IAM.

For everyone else, create groups that mirror how your team actually works: developers, ops-readonly, billing-viewers, whatever fits your org chart. Onboarding becomes “add the new hire to these two groups.” Offboarding becomes “remove them.” A permission change becomes one edit on the group instead of a scavenger hunt across twenty users. Groups are the difference between identity management and identity chaos.

Users and credentials, done right

Each IAM user gets their own identity credentials: a password for console sign-in, and optionally an access key pair (AK/SK) for API and CLI access. A few things worth getting right from day one:

• The password opens the console. Turn on login protection, and go one step further with a virtual MFA device — an authenticator app on the user’s phone that generates 6-digit codes. A password alone is a single factor; MFA is what stands between a phished password and your production network.
• The access key is for programmatic access only: API calls, SDKs, CLIs. It can’t sign in to the console. Treat the secret key like a password — never commit it to a repository, never paste it into a chat thread, and rotate it on a schedule. The docs even include a dedicated guide for handling access key leakage, which tells you how seriously to take this.
• Set the guardrails at the account level: a password policy (length, complexity, rotation) and a login authentication policy (session timeouts, lockout after repeated failures). These apply before anyone even gets a chance to do damage.

Roles vs. policies: coarse and fine

Permissions come in two flavors. Roles are coarse-grained — broad strokes like “can manage ECS” or “read-only viewer.” Policies are fine-grained — precise statements about which actions are allowed on which resources.

For everyday needs, start with system-defined policies. Huawei Cloud ships ready-made policies covering each service’s common actions, and the platform maintains them as services evolve. They cover the 80% case. When you need something they can’t express — “this team may restart ECS instances in the dev project but may not delete them” — write a custom policy. Custom policies are the supplement, not the starting point.

Agencies: delegate without sharing secrets

Two scenarios come up in every real team.

First, another account needs to operate your resources — a partner handling ops, or a separate account per environment. Don’t create an IAM user in your account and email someone the password. Create an agency: a trust relationship between your account and the other account, scoped to exactly the permissions you assign. Their users operate your resources under their own identity, and you revoke the trust in one place when the relationship ends.

Second, one cloud service needs to touch another — an ECS instance reading from an OBS bucket, a FunctionGraph function writing logs somewhere. The wrong answer is baking a long-lived AK/SK into the application. The right answer is a cloud service delegation: you authorize the service to act with a defined permission set, and it picks up temporary credentials automatically. No secrets sitting in config files, nothing to rotate when someone leaves.

If you remember one sentence from this section, make it this: long-lived credentials embedded in applications are a liability; agencies and temporary credentials are the fix.

Scope by project: let regions be boundaries

Here’s a concept that trips up newcomers: in IAM, a region corresponds to a project. Permissions can be scoped to a project, so you can grant “ECS administrator, but only in this region’s project.” For larger organizations, enterprise projects group resources across regions under one governance umbrella.

Used well, this gives you genuine blast-radius control. A developer with rights in the development project simply has no permissions in the production project, no matter what they click. Environment separation stops being a matter of discipline and becomes a matter of configuration.

A setup checklist for this week

If you’re doing this for the first time, here’s the order I’d follow:

1. Put the account credentials in a vault and enable MFA on the account itself.
2. Create groups (admin, developers, ops, billing-viewers) before creating any users.
3. Create one IAM user per human. No sharing, no exceptions.
4. Attach virtual MFA devices to every console user, starting with admin members.
5. Grant permissions to groups with system-defined policies; reach for custom policies only for the exceptions.
6. Issue access keys only to users who genuinely call APIs, and set a rotation reminder.
7. Replace any AK/SK embedded in applications with agency-based delegation.
8. Configure password and login authentication policies — complexity, rotation, lockout, session timeout.
9. Scope permissions by project so development and production stay separated.
10. Review group membership every quarter. Access should follow the org chart, not accumulate like sediment.

Common mistakes worth avoiding

• Everyone lands in the admin group “temporarily.” Temporary has a way of becoming permanent.
• Permissions attached directly to users, until nobody remembers why user #14 can delete databases.
• One shared “devops” IAM user for the whole team. Attribution dies on day one.
• Access keys committed to Git. If this happens, rotate immediately — and assume the old key is already compromised.
• Skipping MFA because “it’s inconvenient.” Incident reports are more inconvenient.

Closing

IAM is not the exciting part of cloud computing. Nobody demos an access policy at a launch event. But it’s the layer that decides whether a 2 a.m. incident is a story about a quick rollback or a story about “we have no idea whose key did that.” The service is free, the concepts fit on a single page, and one focused afternoon of setup buys you attribution, least privilege, and clean separation between environments. Future you — the one debugging at 2 a.m. — will be grateful.