[openstack-dev] [Quantum-core] Proposed Quantum Port SecurityAPI/Blueprint
Aaron Rosen
arosen at nicira.com
Thu Jan 17 21:54:38 UTC 2013
On Thu, Jan 17, 2013 at 3:55 AM, Akihiro MOTOKI <motoki at da.jp.nec.com>wrote:
> Hi Aaron,
>
> >>>>> Date: Tue, 15 Jan 2013 00:40:13 -0800
> >>>>> From: Aaron Rosen <arosen at nicira.com>
> >>>>> Subject: Re: [Quantum-core] [openstack-dev] Proposed Quantum Port
> SecurityAPI/Blueprint
> >
> > In line
> >
> > On Mon, Jan 14, 2013 at 5:28 PM, Akihiro MOTOKI <motoki at da.jp.nec.com>
> wrote:
> >
> > Hi Aaron,
> >
> > # Re-Added openstack-dev
> >
> > >>>>> Date: Mon, 14 Jan 2013 17:05:30 -0800
> > >>>>> From: Aaron Rosen <arosen at nicira.com>
> > >>>>> Subject: Re: [Quantum-core] [openstack-dev] Proposed Quantum
> Port SecurityAPI/Blueprint
> > >
> > > Hi Bob,
> > >
> > > You're right I take back what I proposed before.
> > >
> > > How about having a configuration flag to enforce port_security on
> shared networks?
> >
> > This flag looks unnecessary. If only a owner of a shared network
> (not a
> > owner of a port) is allowed to change port security for the port on
> the shared
> > network, a proper access policy can be achieved.
> >
> > I agree but they wouldn't really be able to do this pro-actively right?
> Would you mind explaining?
>
> Now we allow admin or a owner of a network to specify mac address or IP
> address when port-create/update. This is achieved by
> "rule:admin_or_network_owner" in policy.json.
>
> "create_port:mac_address": "rule:admin_or_network_owner",
> "create_port:fixed_ips": "rule:admin_or_network_owner",
> "update_port:fixed_ips": "rule:admin_or_network_owner",
>
> Can't we use this policy mechanism for port security?
>
> Yup, I just tried that out and it works. I had never used it before.
Thanks!
> I haven't understood what you mention.
> If the above is not what you expected, could you explain more?
>
> Thanks,
> Akihiro
>
> >
> >
> > > > - Why can we disable port security when a port is
> associated with a
> > > > security group?
> > > > The limitation section in the spec document says "if a
> port is
> > > > associated with a security group
> > > > one cannot remove the port security setting as port
> security is
> > > > required for security groups to work."
> > > >
> > > >
> > > > The reason for this is if we allow the vm to change it's
> source ip then
> > > > it would be possible for them to get around the security
> group applied
> > > > to the port.
> >
> > Agreed. If we allow a VM to change it's source ip, source_group does
> not work.
> > When I wrote the mail I did not take care of this case.
> >
> > > > A usual case is a case where a VM wants to another IP
> address in
> > > > addition to its IP address assigned,
> > > > but it is likely a user still wants to use security
> group (to drop
> > > > incoming packets to undesired L4 ports).
> > > >
> > > >
> > > > In this use case you are talking about, are you meaning on
> the same vif
> > > > using ip aliases? If so then the user should update the port
> to include
> > > > this ipaddress and then add the desired security group
> settings for the
> > > > communication they want.
> >
> > Yes. Adding an IP address is a right solution. I missed it.
> >
> > > > It's not possible to support port security on a
> > > > port for only one ipaddress and not the other because of the
> reason i
> > > > mentioned previously. The user could create another port
> with out port
> > > > security though.
> >
> > Thanks,
> > Akihiro
> >
> > >
> > > Aaron
> > >
> > > On Mon, Jan 14, 2013 at 4:45 PM, Robert Kukura <rkukura at redhat.com>
> wrote:
> > >
> > > On 01/14/2013 03:39 PM, Aaron Rosen wrote:
> > > > Hi Akihiro,
> > > >
> > > > Thanks for your feedback. Responses inline.
> > > >
> > > > On Sat, Jan 12, 2013 at 2:44 AM, Akihiro MOTOKI <
> amotoki at gmail.com
> > > > <mailto:amotoki at gmail.com>> wrote:
> > > >
> > > > Hi Aaron,
> > > >
> > > > Sorry for the late feedback.
> > > >
> > > > I have some comments on the spec.
> > > >
> > > > - Who can change the port security? If the network
> physical
> > > > infrastructure provides an address
> > > > space isolation among logical network, a tenant (a
> regular use) may
> > > > change port security freely.
> > > > On the other hand, if the network physical
> infrastructure requires MAC
> > > > uniqueness (for example,
> > > > network_type == flat), only admin should change port
> security.
> > > >
> > > > Correct, I was thinking about building a flag
> > > > (require_port_security_on_shared_networks and
> > > > require_port_security_on_provider_networks) in which it
> would force all
> > > > ports created on that network to use port security (and
> would require
> > > > the admin to remove that setting). Do you think this is
> something we
> > > > should build in?
> > >
> > > I'd recommend not trying to base any behavior on whether a
> network was
> > > created using the provider attributes or not. Once they are
> created,
> > > provider networks are indistinguishable from those created
> from a pool
> > > for a tenant.
> > >
> > > -Bob
> > >
> > > >
> > > >
> > > >
> > > > - Why can we disable port security when a port is
> associated with a
> > > > security group?
> > > > The limitation section in the spec document says "if a
> port is
> > > > associated with a security group
> > > > one cannot remove the port security setting as port
> security is
> > > > required for security groups to work."
> > > >
> > > >
> > > > The reason for this is if we allow the vm to change it's
> source ip then
> > > > it would be possible for them to get around the security
> group applied
> > > > to the port.
> > > >
> > > >
> > > > A usual case is a case where a VM wants to another IP
> address in
> > > > addition to its IP address assigned,
> > > > but it is likely a user still wants to use security
> group (to drop
> > > > incoming packets to undesired L4 ports).
> > > >
> > > >
> > > > In this use case you are talking about, are you meaning on
> the same vif
> > > > using ip aliases? If so then the user should update the port
> to include
> > > > this ipaddress and then add the desired security group
> settings for the
> > > > communication they want. It's not possible to support port
> security on a
> > > > port for only one ipaddress and not the other because of the
> reason i
> > > > mentioned previously. The user could create another port
> with out port
> > > > security though.
> > > >
> > > >
> > > > The current secgroup implementation honors the original
> security group
> > > > implementation in nova
> > > > and IP/MAC spoofing rules are added automatically as
> provider rules.
> > > > We can change the provider rules according to port
> security state
> > > > for the port.
> > > >
> > > > I hope my understanding it correct.
> > > >
> > > > Thanks,
> > > > Akihiro
> > > >
> > > > 2013/1/5 Aaron Rosen <arosen at nicira.com <mailto:
> arosen at nicira.com>>:
> > > > > Hi,
> > > > >
> > > > > I'm starting to work on the following blueprint
> > > > >
> > > > (
> https://blueprints.launchpad.net/quantum/+spec/port-security-api-base-class
> )
> > > > > and would like to run this spec by the community for
> feedback.
> > > > >
> > > > >
> > > >
> https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/
> > edit
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Aaron
> > > > >
> > > > > _______________________________________________
> > > > > OpenStack-dev mailing list
> > > > > OpenStack-dev at lists.openstack.org
> > > > <mailto:OpenStack-dev at lists.openstack.org>
> > > > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >
> > > >
> > > >
> > > > --
> > > > Akihiro MOTOKI <amotoki at gmail.com <mailto:
> amotoki at gmail.com>>
> > > >
> > > > --
> > > > Mailing list: https://launchpad.net/~quantum-core
> > > > Post to : quantum-core at lists.launchpad.net
> > > > <mailto:quantum-core at lists.launchpad.net>
> > > > Unsubscribe : https://launchpad.net/~quantum-core
> > > > More help : https://help.launchpad.net/ListHelp
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Mailing list: https://launchpad.net/~quantum-core
> > > Post to : quantum-core at lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~quantum-core
> > > More help : https://help.launchpad.net/ListHelp
> > >
> > >
> >
> > --
> > Mailing list: https://launchpad.net/~quantum-core
> > Post to : quantum-core at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~quantum-core
> > More help : https://help.launchpad.net/ListHelp
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130117/f2d0ea1e/attachment.html>
More information about the OpenStack-dev
mailing list