You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Lasindu Charith <la...@wso2.com> on 2014/10/25 20:54:34 UTC
Stratos Multi Tenant Management & Isolation [2]
The main purpose of this email is to discuss the design and the
implementation of new Tenant Management in Stratos 4.1.0. As per the
previous email in dev-list [Subject: Stratos Tenant awareness] the main
objective of this implementation is to provide a more granular control over
tenant spaces and it’s users. This will eventually be one of the first
steps of the billing and metering feature we are going to introduce in one
of the future releases.
Let me continue with the proposed design first.
- Stratos core consists of 3 major components/products, SM, AS and CC.
Currently CC and AS are not tenant aware and are exposed as services to
outside. So there is a vulnerability of exposing them to outside to access
without authentication. This issue would become worse if multiple tenants
try to access other tenant’s data via the endpoint without authentication.
Rather CC and AS should not be accessible to users/tenants via as a soap
service and should only be accessible via other servers (SM,AS) or via the
super tenant. As the first step we can make the CC and AS admin services
and set the authorization action to be only accessible for super tenant(s).
By this way other tenant(s) users will not be able to mess around with CC
and AS endpoints.
- Since above 3 components/products will be running in super tenant
mode, there should be a way to pass tenant-wise data without loading the
particular tenant in each component. Basically this will be done by passing
tenantId as a parameter in method calls. For an instance almost all the
service methods of CC and AS will contain tenantId as a parameter and who
ever calls them should pass the relevant tenantId of the required tenant.
- The AS partitions, policies as well as CC data/topology will be
persisted in the super tenant’s registry according to the tenantId for each
and every tenant. The diagram below provides a sample registry data
structure in the super tenant’s registry. One of the major reasons to use
the ST registry to persist tenants’ artifacts in the below design is to
reduce the cost of loading tenants. In addition this data is usually not
sensitive. Data will be persisted with their tenantId and public
definitions will be stored separately. The RegistryManagers of both CC and
AS will do the registry transactions tenant-wise.
- Cloud controller’s singleton FasterLookupDataHolder will be changed to
adapt the tenant-wise data. Some information (data from
cloud-controller.xml) from the current FasterLookupDataHolder will be moved
to a in-memory CommonDataHolder Object and rest of the CC data will be
persisted in tenant-wise FasterLookupDataHolders which will be kept as a
map with tenantIds under a singleton FasterLookupDataHolderManager.
- One of the Major changes in the design applies to the topology since
the topology needs to be tenant-aware as well. So the current
TopologyManager needs to keep tenant-wise topologies in a Map. The
hierarchical topology locking from grouping will also be applicable to the
tenant-wise topologies shown below.
- The messaging component is going through a change. TenantId will be
added to the Event abstract class and should be set via the constructor. So
in all the concrete classes which extends the Event class should set the
tenantId in the constructor itself before publishing the event. This make
all the cartridge instances receive all the events despite of the tenant
they belongs to. In the initial implementation we’ll go with this until we
can come up with tenant-wise topic/messaging model in future.
*Current Issues/Problems*
- When CC/AS components starts, do we need to load all the tenant
information to the in-memory model from the ST registry?
- When sending the Complete topology event what is the better way of
doing?
- To send a single Event with complete tenentIdToTopology Map
- This will be a problem when the topologies are large
- To send one event per tenant Topology (tenantId & Tenant’s topology
as a message)
- This might be a problem when there are many tenants?
- Since if I make a change to any of the above components everything
breaks and there is no way of testing it until everything is in place
correctly, which is really a hard thing to do. Since we currently do not
have integration tests for components (CC/AS) it’s really hard to know what
is going wrong. So as Imesh suggested, I’m doing the changes to the CC
component & Messaging first and test the CC’s basic functionality via the
SOAP endpoint (This will make most of the other components to be not
build-able). Then my plan is to test CC with AS and messaging to verify if
things work fine. Since almost all the component’s are being affected by
this change is there a better way of start implementing/testing the ongoing
work?
Suggestions and comments are highly appreciated.
Thanks,
--
Lasindu Charith
Software Engineer, WSO2 Inc.
Mobile: +94714427192
Web: blog.lasindu.com
Re: Stratos Multi Tenant Management & Isolation [2]
Posted by Lasindu Charith <la...@wso2.com>.
Hi all,
@Gayan: Thanks for the reply. I have created a CompleteTopologyEvent per
tenant containing the tenant's topology. I have not yet implemented lazy
loading of artifacts in the first stage. But yes, it will be needed when we
move on.
I have made the AS, CC, SM, Messaging & REST Ep tenant -aware and did a
simple test for VM scenario. I have not yet added public partition, policy,
cartridge definitions for initial implementation. Still there are changes
to be done for Cartridge Agent, CEP, LB and user subscription. I haven't
tested this kubernetes as well, but since changes are already made, they
should work fine as well.
But with the m3 release going on with python CA, merging grouping branch,
changing event chain to dispatcher etc, I'm not sure whether to proceed
with other changes or not, since it will be really hard to merge
tenant-isolation branch to master later on. Please advice what I can do.
The current changes can be found in
https://github.com/lasinducharith/stratos/compare/apache:tenant-isolation-m2...tenant-isolation-m2-wip-2?expand=1
Thanks,
On Mon, Oct 27, 2014 at 4:40 PM, Gayan Gunarathne <ga...@wso2.com> wrote:
> Hi Lasindu,
>
> I have added some comments in blue.
>
> On Sun, Oct 26, 2014 at 12:24 AM, Lasindu Charith <la...@wso2.com>
> wrote:
>
>> The main purpose of this email is to discuss the design and the
>> implementation of new Tenant Management in Stratos 4.1.0. As per the
>> previous email in dev-list [Subject: Stratos Tenant awareness] the main
>> objective of this implementation is to provide a more granular control over
>> tenant spaces and it’s users. This will eventually be one of the first
>> steps of the billing and metering feature we are going to introduce in one
>> of the future releases.
>>
>> Let me continue with the proposed design first.
>>
>> - Stratos core consists of 3 major components/products, SM, AS and
>> CC. Currently CC and AS are not tenant aware and are exposed as services to
>> outside. So there is a vulnerability of exposing them to outside to access
>> without authentication. This issue would become worse if multiple tenants
>> try to access other tenant’s data via the endpoint without authentication.
>> Rather CC and AS should not be accessible to users/tenants via as a soap
>> service and should only be accessible via other servers (SM,AS) or via the
>> super tenant. As the first step we can make the CC and AS admin services
>> and set the authorization action to be only accessible for super tenant(s).
>> By this way other tenant(s) users will not be able to mess around with CC
>> and AS endpoints.
>>
>>
>>
>> - Since above 3 components/products will be running in super tenant
>> mode, there should be a way to pass tenant-wise data without loading the
>> particular tenant in each component. Basically this will be done by passing
>> tenantId as a parameter in method calls. For an instance almost all the
>> service methods of CC and AS will contain tenantId as a parameter and who
>> ever calls them should pass the relevant tenantId of the required tenant.
>>
>>
>> - The AS partitions, policies as well as CC data/topology will be
>> persisted in the super tenant’s registry according to the tenantId for each
>> and every tenant. The diagram below provides a sample registry data
>> structure in the super tenant’s registry. One of the major reasons to use
>> the ST registry to persist tenants’ artifacts in the below design is to
>> reduce the cost of loading tenants. In addition this data is usually not
>> sensitive. Data will be persisted with their tenantId and public
>> definitions will be stored separately. The RegistryManagers of both CC and
>> AS will do the registry transactions tenant-wise.
>>
>>
>>
>>
>> - Cloud controller’s singleton FasterLookupDataHolder will be changed
>> to adapt the tenant-wise data. Some information (data from
>> cloud-controller.xml) from the current FasterLookupDataHolder will be moved
>> to a in-memory CommonDataHolder Object and rest of the CC data will be
>> persisted in tenant-wise FasterLookupDataHolders which will be kept as a
>> map with tenantIds under a singleton FasterLookupDataHolderManager.
>>
>>
>>
>> - One of the Major changes in the design applies to the topology
>> since the topology needs to be tenant-aware as well. So the current
>> TopologyManager needs to keep tenant-wise topologies in a Map. The
>> hierarchical topology locking from grouping will also be applicable to the
>> tenant-wise topologies shown below.
>>
>>
>>
>> - The messaging component is going through a change. TenantId will
>> be added to the Event abstract class and should be set via the constructor.
>> So in all the concrete classes which extends the Event class should set the
>> tenantId in the constructor itself before publishing the event. This make
>> all the cartridge instances receive all the events despite of the tenant
>> they belongs to. In the initial implementation we’ll go with this until we
>> can come up with tenant-wise topic/messaging model in future.
>>
>>
>>
>>
>> *Current Issues/Problems*
>>
>> - When CC/AS components starts, do we need to load all the tenant
>> information to the in-memory model from the ST registry?
>>
>> As we are maintaining the all the tenant information in the ST mode,IMO
> we can consider easy loading when getting the tenant information to the
> in memory map.
>
>>
>> - When sending the Complete topology event what is the better way of
>> doing?
>> - To send a single Event with complete tenentIdToTopology Map
>> - This will be a problem when the topologies are large
>> - To send one event per tenant Topology (tenantId & Tenant’s
>> topology as a message)
>> - This might be a problem when there are many tenants?
>>
>> It is better if we can maintain it in event per tenant Topology. If we
> maintain like that what is the problem are we en-counting?
>
>
>>
>> - Since if I make a change to any of the above components everything
>> breaks and there is no way of testing it until everything is in place
>> correctly, which is really a hard thing to do. Since we currently do not
>> have integration tests for components (CC/AS) it’s really hard to know what
>> is going wrong. So as Imesh suggested, I’m doing the changes to the CC
>> component & Messaging first and test the CC’s basic functionality via the
>> SOAP endpoint (This will make most of the other components to be not
>> build-able). Then my plan is to test CC with AS and messaging to verify if
>> things work fine. Since almost all the component’s are being affected by
>> this change is there a better way of start implementing/testing the ongoing
>> work?
>>
>>
>> Suggestions and comments are highly appreciated.
>>
>>
>> Thanks,
>> --
>> Lasindu Charith
>> Software Engineer, WSO2 Inc.
>> Mobile: +94714427192
>> Web: blog.lasindu.com
>>
>
>
>
>
>
>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead
> WSO2 Inc. (http://wso2.com)
> email : gayang@wso2.com | mobile : +94 766819985
>
>
--
*Lasindu Charith*
Software Engineer, WSO2 Inc.
Mobile: +94714427192
Web: blog.lasindu.com
Re: Stratos Multi Tenant Management & Isolation [2]
Posted by Gayan Gunarathne <ga...@wso2.com>.
Hi Lasindu,
I have added some comments in blue.
On Sun, Oct 26, 2014 at 12:24 AM, Lasindu Charith <la...@wso2.com> wrote:
> The main purpose of this email is to discuss the design and the
> implementation of new Tenant Management in Stratos 4.1.0. As per the
> previous email in dev-list [Subject: Stratos Tenant awareness] the main
> objective of this implementation is to provide a more granular control over
> tenant spaces and it’s users. This will eventually be one of the first
> steps of the billing and metering feature we are going to introduce in one
> of the future releases.
>
> Let me continue with the proposed design first.
>
> - Stratos core consists of 3 major components/products, SM, AS and CC.
> Currently CC and AS are not tenant aware and are exposed as services to
> outside. So there is a vulnerability of exposing them to outside to access
> without authentication. This issue would become worse if multiple tenants
> try to access other tenant’s data via the endpoint without authentication.
> Rather CC and AS should not be accessible to users/tenants via as a soap
> service and should only be accessible via other servers (SM,AS) or via the
> super tenant. As the first step we can make the CC and AS admin services
> and set the authorization action to be only accessible for super tenant(s).
> By this way other tenant(s) users will not be able to mess around with CC
> and AS endpoints.
>
>
>
> - Since above 3 components/products will be running in super tenant
> mode, there should be a way to pass tenant-wise data without loading the
> particular tenant in each component. Basically this will be done by passing
> tenantId as a parameter in method calls. For an instance almost all the
> service methods of CC and AS will contain tenantId as a parameter and who
> ever calls them should pass the relevant tenantId of the required tenant.
>
>
> - The AS partitions, policies as well as CC data/topology will be
> persisted in the super tenant’s registry according to the tenantId for each
> and every tenant. The diagram below provides a sample registry data
> structure in the super tenant’s registry. One of the major reasons to use
> the ST registry to persist tenants’ artifacts in the below design is to
> reduce the cost of loading tenants. In addition this data is usually not
> sensitive. Data will be persisted with their tenantId and public
> definitions will be stored separately. The RegistryManagers of both CC and
> AS will do the registry transactions tenant-wise.
>
>
>
>
> - Cloud controller’s singleton FasterLookupDataHolder will be changed
> to adapt the tenant-wise data. Some information (data from
> cloud-controller.xml) from the current FasterLookupDataHolder will be moved
> to a in-memory CommonDataHolder Object and rest of the CC data will be
> persisted in tenant-wise FasterLookupDataHolders which will be kept as a
> map with tenantIds under a singleton FasterLookupDataHolderManager.
>
>
>
> - One of the Major changes in the design applies to the topology since
> the topology needs to be tenant-aware as well. So the current
> TopologyManager needs to keep tenant-wise topologies in a Map. The
> hierarchical topology locking from grouping will also be applicable to the
> tenant-wise topologies shown below.
>
>
>
> - The messaging component is going through a change. TenantId will be
> added to the Event abstract class and should be set via the constructor. So
> in all the concrete classes which extends the Event class should set the
> tenantId in the constructor itself before publishing the event. This make
> all the cartridge instances receive all the events despite of the tenant
> they belongs to. In the initial implementation we’ll go with this until we
> can come up with tenant-wise topic/messaging model in future.
>
>
>
>
> *Current Issues/Problems*
>
> - When CC/AS components starts, do we need to load all the tenant
> information to the in-memory model from the ST registry?
>
> As we are maintaining the all the tenant information in the ST mode,IMO we
can consider easy loading when getting the tenant information to the in
memory map.
>
> - When sending the Complete topology event what is the better way of
> doing?
> - To send a single Event with complete tenentIdToTopology Map
> - This will be a problem when the topologies are large
> - To send one event per tenant Topology (tenantId & Tenant’s
> topology as a message)
> - This might be a problem when there are many tenants?
>
> It is better if we can maintain it in event per tenant Topology. If we
maintain like that what is the problem are we en-counting?
>
> - Since if I make a change to any of the above components everything
> breaks and there is no way of testing it until everything is in place
> correctly, which is really a hard thing to do. Since we currently do not
> have integration tests for components (CC/AS) it’s really hard to know what
> is going wrong. So as Imesh suggested, I’m doing the changes to the CC
> component & Messaging first and test the CC’s basic functionality via the
> SOAP endpoint (This will make most of the other components to be not
> build-able). Then my plan is to test CC with AS and messaging to verify if
> things work fine. Since almost all the component’s are being affected by
> this change is there a better way of start implementing/testing the ongoing
> work?
>
>
> Suggestions and comments are highly appreciated.
>
>
> Thanks,
> --
> Lasindu Charith
> Software Engineer, WSO2 Inc.
> Mobile: +94714427192
> Web: blog.lasindu.com
>
--
Gayan Gunarathne
Technical Lead
WSO2 Inc. (http://wso2.com)
email : gayang@wso2.com | mobile : +94 766819985