Multi-account RBAC

Everyone on the team uses the same Outscale credentials. The intern has the same access as the infrastructure lead. The contractor can see billing data, modify schedules, and delete snapshots. Nobody knows who changed what, because everyone is "admin."

This isn't unusual. It's the default state of most cloud teams before someone gets burned. A bad change with no author. A bill spike nobody can explain because three people had access. A contractor who left and still has keys.

You know you need proper access control. You just haven't had a tool that makes it easy.

What it does

Multi-account RBAC gives every team member exactly the permissions they need — per account — with three built-in roles and fully custom overrides when the roles don't fit.

• Viewer — read-only access. See costs, schedules, and resources. Can't change anything.
• Editor — read + write. Create schedules, run operations, modify settings. Can't manage users or billing.
• Admin — full access. Everything, including user management and account settings.

Need something in between? Custom permissions let you cherry-pick exactly which actions a user can perform. A finance analyst who can see costs and budgets but nothing else. A junior engineer who can view schedules but not modify them. A contractor with access to one account but not others.

How it works

Invite collaborators by email. Choose their role — viewer, editor, or admin — for each account they should access. They get an invitation, accept it, and immediately have the right access. No shared passwords, no credential sharing.

Each user sees only what they have permission to see. A viewer on the dev account and an editor on staging sees both accounts in the sidebar, but with different capabilities on each. The UI adapts — buttons and actions that require higher permissions are hidden, not grayed out.

For teams managing multiple Outscale accounts, permissions are per-account. You can be an admin on the dev account and a viewer on production. The permissions follow the account, not the user. This is how real teams work — different people have different roles on different environments.

Custom permissions go deeper. The built-in roles are starting points. If you need a role that doesn't exist — "can manage schedules and view costs, but can't touch operations or billing" — build it. Toggle individual permissions on or off, per user, per account.

Every permission change is audited. You can see who granted access, who revoked it, what changed, when. The audit log is the proof that your access control policy is being followed.

Why it matters

Access control isn't about trust. It's about blast radius. When an intern accidentally deletes a schedule, the question isn't "do we trust the intern?" — it's "why did the intern have delete access in the first place?"

Proper RBAC reduces blast radius. A viewer can't break anything. An editor can break their area but not yours. An admin can break everything — and that's why there should be few of them.

For compliance, RBAC is usually a requirement, not a feature. SOC 2, ISO 27001, and most enterprise security policies mandate role-based access and audit trails. Multi-account RBAC gives you both, without building a custom IAM system on top of your cloud tooling.

The collaborator invitation flow means no more "send me the credentials." No more shared passwords in a Slack channel. No more "who has access to what?" — the permissions page answers that question in one click.

Give your team the access they need. Nothing more. Start your free trial on Vextnd.