You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Jeff Hair <je...@greenqloud.com> on 2014/03/24 17:12:43 UTC
[PROPOSAL] More Flexible Security Group Implementation
Hi,
Currently the security group manager has a very specific implementation
that requires an agent running on the other end. This works for KVM but not
for other hypervisors such as VMware. The validation mechanisms are also
very tightly coupled to the large methods in the NetworkManager and
UserVmManager.
I'd like to propose a more flexible way of handling security groups,
perhaps called SecurityGroupGuru.
Major points:
- Instead of having hard checks like "if (isVmWare) throw
InvalidParameterValueException" when it comes to security groups, the
various managers would loop through the set of security group gurus until
they find a guru that supports the desired configuration (combination of
hypervisor, zone type, network type).
- The SecurityGroupManagerImpl will now send jobs off to the
SecurityGroupGuru to handle, instead of handling the job itself. For
example, a KvmSecurityGroupGuru would handle the jobs as they are now. A
new VmwareSecurityGroupGuru could be implemented for VMware, etc.
The main desire for this proposal is to to allow extensible security group
implementations that don't have to override extremely large methods to
change their behavior on a few lines.
Some possible use cases of this include:
- Changing security group behavior. Instead of having the security
groups on a physical host, they could be put on a virtual router.
- A foundation for security groups in isolated advanced-mode networks.
- Organized, maintainable implementations of security groups for
different hypervisors.
Thanks,
Jeff
Re: [PROPOSAL] More Flexible Security Group Implementation
Posted by Jeff Hair <je...@greenqloud.com>.
Hi,
If the isVmWare checks are removed, what would they be replaced with
instead? Would it be an additional method in the Security Group Manager?
On Mon, Mar 24, 2014 at 5:40 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
> Hi, I believe the right layer of abstraction is present in the SG manager
> (and yes, we should remove isVMWare checks). This abstraction works at the
> 'policy' level: which IP/VM is allowed to talk to which VM/IP. This policy
> is translated into a concrete implementation by the resources. So I don't
> like the idea of hypervisor-specific gurus (network gurus should be
> agnostic of the hypervisor)
>
> From: Jeff Hair <je...@greenqloud.com>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Monday, March 24, 2014 at 9:12 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: [PROPOSAL] More Flexible Security Group Implementation
>
> Hi,
>
> Currently the security group manager has a very specific implementation
> that requires an agent running on the other end. This works for KVM but not
> for other hypervisors such as VMware. The validation mechanisms are also
> very tightly coupled to the large methods in the NetworkManager and
> UserVmManager.
>
> I'd like to propose a more flexible way of handling security groups,
> perhaps called SecurityGroupGuru.
>
> Major points:
>
> - Instead of having hard checks like "if (isVmWare) throw
> InvalidParameterValueException" when it comes to security groups, the
> various managers would loop through the set of security group gurus
> until
> they find a guru that supports the desired configuration (combination of
> hypervisor, zone type, network type).
> - The SecurityGroupManagerImpl will now send jobs off to the
> SecurityGroupGuru to handle, instead of handling the job itself. For
> example, a KvmSecurityGroupGuru would handle the jobs as they are now. A
> new VmwareSecurityGroupGuru could be implemented for VMware, etc.
>
> The main desire for this proposal is to to allow extensible security group
> implementations that don't have to override extremely large methods to
> change their behavior on a few lines.
>
> Some possible use cases of this include:
>
> - Changing security group behavior. Instead of having the security
> groups on a physical host, they could be put on a virtual router.
> - A foundation for security groups in isolated advanced-mode networks.
> - Organized, maintainable implementations of security groups for
> different hypervisors.
>
>
> Thanks,
>
> Jeff
>
>
Re: [PROPOSAL] More Flexible Security Group Implementation
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Hi, I believe the right layer of abstraction is present in the SG manager (and yes, we should remove isVMWare checks). This abstraction works at the ‘policy’ level: which IP/VM is allowed to talk to which VM/IP. This policy is translated into a concrete implementation by the resources. So I don’t like the idea of hypervisor-specific gurus (network gurus should be agnostic of the hypervisor)
From: Jeff Hair <je...@greenqloud.com>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Monday, March 24, 2014 at 9:12 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Subject: [PROPOSAL] More Flexible Security Group Implementation
Hi,
Currently the security group manager has a very specific implementation
that requires an agent running on the other end. This works for KVM but not
for other hypervisors such as VMware. The validation mechanisms are also
very tightly coupled to the large methods in the NetworkManager and
UserVmManager.
I'd like to propose a more flexible way of handling security groups,
perhaps called SecurityGroupGuru.
Major points:
- Instead of having hard checks like "if (isVmWare) throw
InvalidParameterValueException" when it comes to security groups, the
various managers would loop through the set of security group gurus until
they find a guru that supports the desired configuration (combination of
hypervisor, zone type, network type).
- The SecurityGroupManagerImpl will now send jobs off to the
SecurityGroupGuru to handle, instead of handling the job itself. For
example, a KvmSecurityGroupGuru would handle the jobs as they are now. A
new VmwareSecurityGroupGuru could be implemented for VMware, etc.
The main desire for this proposal is to to allow extensible security group
implementations that don't have to override extremely large methods to
change their behavior on a few lines.
Some possible use cases of this include:
- Changing security group behavior. Instead of having the security
groups on a physical host, they could be put on a virtual router.
- A foundation for security groups in isolated advanced-mode networks.
- Organized, maintainable implementations of security groups for
different hypervisors.
Thanks,
Jeff