Skip to main content

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!

3 comments

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

      Team•

      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

    Team•

    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 default domain ?