...
- ONLY minimal impacting changes will be accepted in G 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 G 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 G 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.No replication of the central namespace.
Current proposed design (will evolve as we go)
Drawio border true diagramName Policy Framework Multi-tenancy simpleViewer false width links auto tbstyle top lbox true diagramWidth 921 revision 5
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
- Policy types