Reseller Support Without Requiring Separate Keystone Domains
Summary
Enable the creation of reseller accounts within the default domain, avoiding the need to create and manage separate Keystone domains for each reseller.
Background
In our current understanding of OSIE’s tenancy model, resellers are implemented by creating a dedicated OpenStack Keystone domain, with customer projects created within that domain.
While this provides a logical separation between resellers, it introduces additional operational overhead and complexity.
Current Behaviour
Creating a reseller requires provisioning a new Keystone domain
Each domain operates with isolated identity management
Shared resources such as images, flavours, and networking constructs require additional configuration to be made accessible across domains
This leads to:
Duplication of configuration
Increased administrative overhead
Risk of inconsistency between domains
If this functionality already exists or can be achieved through an alternative design, we would appreciate any documentation or guidance on recommended best practices.
Problem
For service providers operating a multi-tenant platform, the requirement to create separate domains per reseller introduces unnecessary complexity when:
The underlying infrastructure (compute, storage, networking) is shared
Standardised offerings (flavours, images, policies) are centrally managed
Operational consistency across all customers is required
Managing multiple domains makes it harder to:
Maintain a single catalogue of images and flavours
Apply consistent policy and governance
Streamline onboarding and automation workflows
Desired Behaviour
Allow resellers to be created within the default domain, using constructs such as:
Project hierarchy (nested projects / parent-child relationships)
RBAC and role-based delegation
Scoped administrative permissions per reseller
This would allow:
Logical separation of resellers
Delegated control to reseller administrators
Continued use of centrally managed shared resources (images, flavours, etc.)
Example Workflow
A reseller is created as a top-level project (or organisational unit) within the default domain
Customer projects are created beneath the reseller
The reseller is granted administrative permissions scoped only to their projects
Shared resources remain centrally managed and accessible without duplication
Benefits
Reduced operational overhead
Simplified resource management
Consistent service catalogue across all tenants
Easier automation and onboarding
Improved scalability of the platform
Thanks!
Log in to comment and vote
Comments3
Kevin.Pannell
Mar 20
Hi Marius
Thanks for the clarification, that makes sense from the perspective of resellers operating as fully independent providers with their own OSIE instance and domain-level control.
Our use case is slightly different, so I just wanted to clarify how we are looking to model this.
In our platform, resellers are not intended to operate independent OSIE instances or have full domain-admin control. Instead, they act more as a commercial and operational boundary, where:
The underlying infrastructure remains centrally managed by us
Standardised services (images, flavours, policies, etc.) are shared across all tenants
Resellers require the ability to manage only their own customer projects
From this perspective, the requirement is more aligned to:
Delegated administration at a project or project hierarchy level
Scoped visibility and control limited to a reseller’s customers
Continued use of centrally managed shared resources without duplication
The challenge we are facing with the current domain-per-reseller model is that it introduces additional operational overhead and fragmentation, particularly around maintaining consistency of shared resources and service definitions.
Given this, we wanted to ask:
Is there a supported or recommended approach within OSIE/OpenStack to enable delegated reseller-style access within a single domain, without requiring full domain separation?
For example, using:
Project hierarchies (nested projects)
RBAC and scoped roles
Policy-based access controls
If this is not currently supported, we believe this could be a valuable enhancement to support service providers who operate a centrally managed platform with reseller-style delegation, rather than fully independent environments.
Happy to discuss further if useful.
Thanks!
Marius Leustean
Mar 26
Hi Kevin,
There are some RBAC features coming with the Organisation/Company Concept where people can receive fine-grained access on Organizations or even on individual projects.
I’ve subscribed you to be notified once that’s released.
I believe, the reseller’s Billing Profile can be assigned to multiple Organizations or even individual Projects, then normal users would receive non-billing, restricted RBAC on those projects.
Marius Leustean
Mar 20
The current design is involving 1 Domain per Reseller because the reseller is supposed to get domain-admin access and deploy it’s own OSIE instance to sell services.
With that in mind, how will you allow the reseller to self-service projects and tenants within a shared
defaultdomain ?