Multi-tenancy support in Policy Framework

Owned by Ram Krishna Verma
Last updated: Dec 07, 2020
2 min read

This page aims to describe the design, architecture & impacts of multi-tenancy support in Policy Framework project.

As discussed, in the last meeting (Friday, 10th July)

  • ONLY minimal impacting changes will be accepted in H release timeframe.

Current Blockers (which must be solved before proceeding)

  • DMaaP communication over multiple namespaces.

  • Policy DB communication over multiple namespaces. Mainly the security credentials generated randomly during DB pod creation.

  • Planning of what policy components needs to be centralized vs de-centralized and moved to tenant namespaces.

  • How DCAE/OOF or any other client decides which PDP engine to call for making decision. This is valid for scenarios where clients are making a REST (or any) call directly to PDP engine. Currently supported by Xacml-PDP.

  • Are there any impacts to CLAMP or any other clients who want to create/deploy policy in PDP Groups.

  • PDP in tenant namespace needs to check during initialization that DB is ready in the central namespace.

  • PDP → DB latency will increase if DB is in central namespace (Can be solved by splitting & moving DB to tenant namespace).

Scope for H release 

  • Create a PdpGroup per tenant. And decide which & how many PDP instances are needed depending upon the tenant needs. 

  • Deploy/Undeploy policies to specific tenant based PdpGroup. 

  • Manage multiple PdpGroup & PDP instances from PAP.

  • Health check for all PDP instances from PAP.

Limitations for H release (which will be solved in later releases) 

  • PDP engines will communicate to Policy DB in centralized namespace. Resulting in using same DB to store operations history data of multiple tenants.

  • One instance of drools-pdp can ONLY be configured to call a specific CDS instance for taking control loop actions using CDS actor.

  • No provision of authentication & authorization of user across multiple tenants.

Current proposed design (will evolve as we go)





Policy Weekly meeting updates (12th Aug 2020)

  • Need to figure out how Multi-Tenancy aligns with Multi-Cluster deployments.

  • Xacml-PDP needs load balancer for cases where numerous requests are generated by operational policy, resource instantiation etc.

    • Routing is needed, to ensure the request goes to the XACML-PDPs for a given tenant.

    • Load-balancing is needed so that load can be distributed across the XACML-PDPs for a given tenant.

  • Tenants are assumed to be use case/domain specific with their own Analytics component.

  • Tenants are assumed to only work towards specific devices for the use case/domain.

  • Need for Service Discovery or similar feature to make Xacml-PDP across multiple tenants resolvable by clients - DCAE, SDNC, Drools-PDP, OOF.

  • Need to verify how DCAE Analytics consume the Policy Update Notifications.

  • DB information must be appropriately handled:

    • Policy types

      • XACML-PDP needs access to the policy types.  One solution is to change Xacml-PDP to pre-load required policy types instead of calling Policy DB.

    • Policies

      • Only needed by API & PAP, thus can remain in the central namespace

    • Operations History

      • Can be segregated by tenant

    • Distributed Locks

      • Can be segregated by tenant if locking is only required across a single tenant

      • Must address the multi-cluster case; perhaps use MUSIC for this case