edgeContinuum ships a hierarchical, scope aware permission model: users and groups, roles you compose yourself out of more than 200 individual permissions, granted across a whole organization or inside a single project. Fine grained enough that an operations team can restart a machine without being able to delete it.
Most private cloud platforms hand you a short list of built in roles and a set of policy files to edit by hand. The result is familiar: the network on call engineer who needs to reboot a machine at 3am ends up with an account that can also delete it, a client team shares one administrator login because there is no way to give three people three different levels of access, and the platform team becomes the queue in front of every permission change. Nobody chose that, it is just what a coarse model leaves you with. edgeContinuum treats authorization as a product surface: every action the platform exposes is its own permission, roles are composed from those permissions, and each grant carries the scope it applies to.
Four things move. None of them requires a new identity provider, and none of them asks your teams to learn a policy language.
Every grant answers two questions: what can this person do, and where. A role given at organization scope applies across that organization, and for the permissions that carry it, straight down into every project inside it. A role given at project scope stops at that project's edge. Same role, two blast radii, and the console tells you which scopes a permission supports before you use it.
That is what makes delegation safe. A client administrator runs their own organization, invites their own people and creates their own projects, while the platform permissions that would let them touch regions, infrastructure or the service catalog stay with you.
If you run OpenStack, the natural question is how this relates to Keystone. Keystone models identity and each OpenStack service carries its own policy, which is why expressing "restart it but never delete it" usually means editing policy files by hand. edgeContinuum keeps Keystone exactly where it is and runs its own users, groups, roles and permission catalog for the services it exposes, so the two models are not required to mirror each other. The guide to users, projects, roles and quotas in OpenStack covers what Keystone models natively and where that stops.
Permissions can go directly to a user when that is genuinely a one off. For everything that describes a team, use a group: put the people in it, give the group a role at the scope you want, and membership becomes the only thing you maintain. Groups take grants at organization scope and at project scope, exactly like users do.
A service provider ends up with something like this: NOC engineers sit in one operations group holding an organization wide operational role, so they can act on anything in the estate without being able to destroy it. A client's development team gets a role on its own project and sees nothing else. When someone leaves the rotation you remove them from the group, not from fourteen projects.
Here is an operations role composed in the console, the kind a NOC runs on. It can look at anything, restart a machine, open its console, read its logs and scale a node pool. It cannot delete a virtual machine, resize one, download a cluster kubeconfig, change a firewall rule or hand out permissions to anyone else. Every line below is a real permission identifier from the platform's catalog, which is what you see and search when you compose the role.
Roles are authored per organization rather than shipped as a fixed ladder, so the same platform carries an org-admin for a client's own administrator, a db-operator that only touches databases, and a read only role for whoever needs to look without touching. Permissions also imply one another where it makes sense: granting a broad read on Kubernetes grants the narrower reads underneath it, and the console shows how many other permissions a grant carries with it.
This is the difference between an access model bolted onto infrastructure and one that belongs to a managed cloud. The catalog covers the machines and the networks, and equally the managed Kubernetes clusters, the managed PostgreSQL instances, the regions and zones your infrastructure is shaped into, the quota profiles applied to each tenant and the usage figures per organization.
Which means the delegation you design holds everywhere. There is no service where the model quietly falls back to all or nothing.
Virtual machines and SSH keys, plus images and flavors. Create, power, console, logs, metrics, snapshots, resize, import and delete are each their own permission.
Networks, firewalls and routers, down to the level where changing a rule or a route is its own permission, separate from reading them.
Kubernetes, including control plane upgrades and resizes, node pool scaling and the kubeconfig itself, and PostgreSQL down to its connection details.
Organizations, projects, groups, role assignment and quota profiles, plus infrastructures, regions and zones, and the usage figures per tenant.
The model exists so that responsibility can move outward without control moving with it. Four typical positions, each one a role composed from the catalog and granted at the scope its job needs.
Yours. Connects infrastructures, defines regions and zones, curates the catalog, creates organizations and sets the quota profiles each one gets. The only role that reaches the platform itself.
Your client, or a business unit lead. Invites users, builds groups, creates projects and assigns roles inside their own organization, against the quota you granted them. Sees nothing outside it.
The role above. Organization wide reach for operational work: restart, console, logs, metrics, node pool scaling. No deletes, no credentials, no permission changes.
Scoped to one project. Creates and manages the clusters, databases and machines that project needs, inside its quota, and cannot see or touch any other project in the organization.
Bring the teams and clients you actually have, and we will map them onto organizations, projects, groups and roles on a call. Or start a free trial and build a role yourself.
