[openstack-dev] [Quantum-core] Proposed Quantum Port SecurityAPI/Blueprint
Akihiro MOTOKI
motoki at da.jp.nec.com
Thu Jan 17 11:55:14 UTC 2013
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?
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
>
>
More information about the OpenStack-dev
mailing list