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 G 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 G 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 G 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.
- No replication of the central namespace.
Current proposed design (will evolve as we go)