Mapping of CloudStack access control concepts to AWS

[rhysperry111]

We're slowly starting to look to deploy CloudStack to form some kind of hybrid cloud with our AWS environment, and at least from a first glance it's proving a little difficult to understand CloudStack permissions concepts in the lens of how things work in AWS.

In AWS, we have an organisation (everything) which is compromised of multiple accounts (isolated resource environments), and each of these accounts have associated roles (permission levels) that authenticated users can assume providing they are in the correct authentication group.

We initially were working on the idea that we would have a singular CloudStack domain which was equivalent to our AWS organisation, and multiple accounts in CloudStack which were equivalent to our AWS accounts, however this started to fall apart when we realised that multiple users in the same CloudStack account cannot have different roles, and you cannot have multiple users of the same username (but different accounts) within the same CloudStack domain. There also seems to be no way to create a CloudStack account without also creating a user to go with it?

Is it that domains in CloudStack are a more similar concept to AWS accounts, and accounts in CloudStack are similar to AWS roles?

Apologies if this is a bit of a dumb question, however reading over the documentation didn't clarify things up too much more, and we can't begin deploying our own demo to test things ourselves until we have a basic understanding of how such a core concept of the solution will work.

[bradh352]

We use "Projects" for that purpose, where we can add multiple accounts to a project and can share the resources created there.

An account is really a single user (though yes, you can have multiple user accounts which is confusing, I'm not entirely sure of that purpose, but I do see cloudstack auto-generate things like k8s users under your account).

I honestly haven't looked into how fine grained you can get on permissions when adding an account to a project, however.

[rhysperry111]

We did initially look at projects, however weren't entirely satisfied with their isolation from a user perspective.

There are many views in CloudStack that allow you to see resources from all of the account's projects in a single list, and in the environment we're working with this likely won't be acceptable (especially if different accounts/projects may have very different regulatory expectations).

In AWS it's very clear that accounts are entirely separate, and it's a very conscious choice for users to pick their account or switch between them.

[drynoa]

Have you looked into domains under domains? (sub-domains) Roles for accounts in the root domain give some level of control (such as domain admin), with that sub-domains could be equivalent to accounts in AWS and users in AWS to accounts. Not very fine grained but more usable.

[rajujith]

@rhysperry111 Yes the roles are tied to the Account in CloudStack. Based on your use case, you could map like this: Organization -> Domain, Account (resource ownership, provides isolation), with one user (human login) assigned the desired role type (permission level) per user.

[rhysperry111]

Yeah we'll likely be looking at an approach like this.

A little odd that there's no way to provide different roles to different users for the same set of isolated resources, as the resources are scoped to the account and not the domain.

[DaanHoogland]

sounds like a lingering feature request @rhysperry111 ?