vmware-nsx specific policies are defined as policy-in-code.
- vmware_nsx/policies/lsn.py, qos_queue.py and maclearning.py
are moved from the neutron repo.
- vmware_nsx/policies/providersecuritygroup.py is based on the difference
between etc/policy.json and the old neutron policy.json
- vmware_nsx/policies/security_group.py is based on
etc/policy.d/security-groups.json
- vmware_nsx/policies/network_gateway.py is based on
etc/policy.d/network-gateways.json
etc/policy.d/dynamic-routing.json and etc/policy.d/neutron-fwaas.json
have no policies specific to vmware-nsx, so they can be dropped and
we can use policy-in-code definitions in neutron-fwaas and
neutron-dynamic-routing.
etc/policy.d/routers.json and flow-classifier.json cannot be
converted into policy-in-code because the default policies are
different from those defined in neutron and networking-sfc.
Note that etc/policy.d/routers.json now has policies which are
different from the default policies defined in the neutron repo.
(Others are clean up by this commit.)
This commit depends on the following patches under review:
(neutron-fwaas policy-in-code support)
Depends-On: https://review.openstack.org/527282
(neutron-dynamic-routing policy-in-code support)
Depends-On: https://review.openstack.org/625429
(networking-sfc policy-in-code support)
Depends-On: https://review.openstack.org/625431
(Drop 3rd-party plugin specific policies)
Depends-On: https://review.openstack.org/625394
Partially Implements: blueprint neutron-policy-in-code
Co-Authored-By: Michal Kelner Mishali <mkelnermishal@vmware.com>
Co-Authored-By: Adit Sarfaty <asarfaty@vmware.com>
Change-Id: I96a9dbd759d54308abbc12ce65c97b06a76453cd
update_router:external_gateway_info and create_router:external_gateway_info
are the same as those defined in neutron.
We should only have the ones that are different.
Change-Id: I7cbf03722567401ec3622e941d4b4af1cf63c0c9
This patch move away some policy rules from policy.json file and place
them under a designated policy file under policy.d directory.
Change-Id: I0e91c384a0d7c1ddfa1d5ea5756bf851760539ab
This code adds an extension for policy-id in a security group.
when this feature is enabled (new nsxv config: use_nsx_policies):
- Each security group will be linked to an nsx policy.
- No rules will be added to any of the security groups
- Only admin can edit security groups (depending on the policy.json)
- the default security group will be using the new nsx.ini config
default_policy_id
Change-Id: Iad5e90245c2f70ed88f65f0c5e6ec46cb2eedbbc
This patch set introduces a new feature called provider-security-groups.
Provider security groups allow the provider to create a security group
that is automatically attached to a specific tenants ports. The one
important thing to note is that rules inside of a provider security
group are set to DENY where as a normal security group they are set
to ALLOW. Provider security groups allow the admin tenant to block specific
traffic for any tenant they like by creatng a provider group. To use this
feature the admin tenant must first create a provider security group
on behalf of the other tenant (i.e):
$ neutron security-group-create no-pokemon-go-access --provider=True \
--tenant-id=<shall remain nameless>
Then, whenever the above tenant id creates a port they will see a an
additional field on the port "provider-security-groups" which will
contain the uuid of the provider security group. This user can then
query neutron to see which rules are in it that are blocking them.
NOTE: one needs to use the correct policy.json file from this repo
for neutron inorder to prevent the tenant from removing the group.
Co-Authored-By: Aaron Rosen <aaronorosen@gmail.com>
Change-Id: I57b130437327b0bbe5cc0068695f226b76b4e2ba
The service insertion feature allows us to redirect some of the NSX traffic to an external
security vendor like Palo-Alto or checkpoint for advanced inspection.
The implementation contains:
Enable the flow classifier plugin, and use it to create redirect rules on NSX
When the flow classifier plugin is initialized a new security group is created
and added to the configured service profile
When a vm port with port security is created/updated, it is added to this security group
When the admin user create a flow classifier entry, a backed redirect rule will be created.
DocImpact: new NSXV Configuration parameters:
service_insertion_profile_id = <service profile id, i.e. serviceprofile-1>
DocImpact: The flow classifier methods should be added to the policy.json as admin only
Change-Id: I67a132d4b35764c6940516a8365a2749d574aad2
The policy rule for delete_gateway_device is not valid because of
the typo. This commit fixes the issue.
Change-Id: I9f4f970193ba62800bc538825f82f1600552450b
This patch is a follow up to the auto generate config file patch[1]
which removes the static example nsx.ini file from the repo as
it is now redundant.
[1]: https://review.openstack.org/#/c/303673/
Depends-On: Iff4ea37b52616295b262ead53947acb5b0cd9cd7
Change-Id: I61ee6fe873cfeac9dfe6d9eb7b0f90dd7c251d51
Partial-bug: #1568215
This patch adds support to automatically generate config files
for vmware-nsx repo using oslo config generator[1] for all
VMware plugins.
Tox can be used to generate a sample config file using the
following command:
tox -e genconfig
This will generate a config file "nsx.ini.sample" under
vmware-nsx/etc/ folder.
This patch also modifies devstack scripts to use the
auto-generated config files and adds more information to help
texts in config modules.
[1] http://docs.openstack.org/developer/oslo.config/generator.html
Change-Id: Iff4ea37b52616295b262ead53947acb5b0cd9cd7
Partial-Bug: #1568215
The firewall rule created on the differents edges to allow access
to the metadata service, should be restricted to the specific
supported protocols (tcp 80, 443, 8775), and not open to all protocols
The list of allowed ports can be extended using the nsx.ini parameter
'metadata_service_allowed_ports'
Change-Id: If2f0f30937eb3b7489a36feff1635de4822710bb
At NSXv version 6.2.3 and higher, dhcp options 121,66/67,150 and 26 is
supported. This patch enhanced dhcp metadata support via using option121
to insert metadata host route into VMs. So that VM doesn't
need to insert a metadata host route manually for dhcp metadata support
case.
Change-Id: I1e051903f5b136308634346c6d546118bfc9bbe9
Allows admin to control security-groups rule logging
NSXv distributed firewall expose an API to control rule logging,
as for the moment, admin user can use this feature only from inside of
the distributed firewall.
This patch make use of this API to provide the cloud admin with three ways
to control security-group logging:
- log whenever security-group rule is matched
- log when a packet doesn't match any security-group rule
- log whenever security-group rule is matched for selected
security-groups
Change-Id: I2a4dbff2ecba4c6041b4aaad1f20941440a5f6b6
Since we can get edge cluster and edge members info from
default_tier0_router_uuid, the default_edge_cluster_uuid is totally
useless. The patch removes all default edge cluster relative codes.
Change-Id: I9f9a7fdc1c4c8d67a22ef58564d749e53048ee18
u
Change the default value of metadata_on_demand from True to False
because the following reasons:
1. Due to current dnsmasq bug, new VMs on a DHCP-enabled subnet may still
get the metadata route to DHCP port via dnsmasq DHCP options. Once the
bug is fixed, new VMs will get the metadata route to router port via
dnsmasq DHCP options. If we have metadata_on_demand=False and
force_metadata=False, we can always have internal metadata network
ready, which can handle the metadata requests routed to the router
port if the dnsmasq bug is fixed.
2. According to current DHCP agent implementation, if DHCP agent is
restarted, it will try to restart all metadata proxies. But it will
skip the metadata proxy for a network that has any subnet attached
to a router. Instead, DHCP agent will start a metadata-proxy for the
router. If old metadata proxy processes are still running, then it
should be fine. But consider the case when a openstack network node
is restarted, then all old processes are gone. Thus DHCP agent will
not start those metadata proxies for networks with attached router.
This means any VM that has routing table containing a metadata route
to the DHCP port will fail to reach metadata service because the
corresponding metadata proxy that handle 169.254.169.254:80 is not
running.
3. When (2) happens, if we have force_metadata=True, dnsmasq will
provide metadata route to DHCP port for any new VM on a DHCP-enabled
and router-attached subnet. So those VMs will fail to reach metadata
service.
4. When (2) happens, if we have force_metadata=False, dnsmasq will
provide metadata route to router port for any new VM on a DHCP-enabled
and router-attached subnet. If metadata_on_demand=False, the
pre-created internal metadata network can forward the metadata
requests from those VMs. But if metadata_on_demand=True, the internal
metadata network is not created because the router is attached to a
DHCP-enabled subnet. Thus the router can not route those metadata
requests.
Also fix metadata tags used in NSX|V3 unit tests.
Change-Id: I6d39dffa365f172ad24530ee938b5af3483a7a18
Previously, an internal metadata network is created
for a router whenever a subnet is attached to this router.
The purpose of this internal network is to help processing
metadata requests from instances on DHCP-disabled networks.
This commit adds a config option to create internal metadata
networks only when a DHCP-disabled subnet is attached to a router.
This will help saving system resources because each metadata
network consumes one DHCP name space.
Change-Id: Ia56050b3f431dbd65bb39da29ba6dbf8e62e36ea
The number_of_nested_groups details is missing from nsx.ini,
adding it to provide better details to the user.
Change-Id: I5339d01c1ded0f37860b8bc8069683ae6d7e1627
This patch removes the NSX v3 client cluster logic that
forces a revalidate of all endpoints when endpoint
selection only finds DOWN endpoints. The revalidate
call can cause cascading backpressure under certain
circumstances.
Now DOWN endpoints are only returned to UP as part
of the endpoint keepalive ping that is controlled via
conn_idle_timeout config property. Thus, the default
conn_idle_timeout is also decreased to 10s ensuring
endpoint revalidation occurs (by default) on a fequent
basis.
backport: liberty
Change-Id: I5423bce793892dd864353a23ca7c288b846a1ab6
Closes-Bug: #1541591
This patch changes the defaults for the retries and http_timeout
conf properties in the nsx_v3 group of nsx.ini.
backport: liberty
Change-Id: I971701524e68a30fec580ef27faccdde46ccfd68
Closes-Bug: #1540463
This patch adds a new conf property to the nsx.ini under the
nsx_v3 group called http_retries. This value is used for the
max retries used on HTTP requests. Additionally this patch
clarifies the use of http_retries vs retries in the conf properties.
A unit test is also included.
backport: liberty
Change-Id: Ifb0d1aaa6a11163f6520a6472ef743e3eab3ce38
Closes-Bug: #1540885
This patch exposes a new config property named
http_read_timeout in the nsx_v3 group of nsx.ini
which allows users to configure a HTTP read timeout
separately from http connect timeout (set via http_timeout).
With this addition users can provide finer grained timeout
settings for their deployed env.
A unit test is also included.
backport: liberty
Change-Id: I6bcb142329e348c7b2224daf32bd3f648ff2af77
Closes-Bug: #1540462
The configuration names nsx_* have been changed to nsx_api_*.
This better refelect the configuration and management of the NSX API
service.
Change-Id: I999f56efad1b413bc677a9de8b535f3f4785e4f5
Closes-bug: #1524659
This patch adds multi-manager support to the
NSX v3 plugin thereby enabling the ability to specify multiple
NSX managers for the v3 plugin.
This implementation supports the same basic features
as the MH multi-manager support does including;
timeouts, retries, keep-alive, etc..
The approach in a nutshell is to introduce a "proxy"
class which looks like a requests or requests.Session
object and can be used in place of requests in the
NSX REST API client. Under the covers this class handles
management of endpoint selection and connectivity.
Also note that with this patch your devstack local rc / conf
no longer needs to specify NSX_CONTROLLERS when using
the v3 plugin. Instead a comma list of managers is supported
on the NSX_MANAGERS devstack var.
Closes-Bug: #1524046
Change-Id: I433a4b9ea73de0680d64d86e2f826c092adfba87
Metadata service in the NSX-V plugin is handled by a Edge DHCP or
router VM. Currently the traffic between nova and the metadata service
is insecure. This patch adds the SSL support for metadata service
which will make the connection secure.
The certificate used for secure communication will be created on the
VC under the edge scope. If user does not supply the certificate and
private key for secure communication, a self signed certificate will be
generated in the backend. This self signed certificate will last for a
period of 10yrs.
A certifcate with the given details will be created in the backend if
such a configuration exists in nsx.ini
Appropriate config is pushed for the loadbalancer with the protocol set
to HTTPS if SSL is enabled for metadata service.
DocImpact
Change-Id: I5582cc1186ef4b8451f999b46e55bc2c684b1be3
The variable will now be in the 'DEFAULT' section. This is due to the
fact that it is used by the NSX|V and NSX|V3 plugins.
DocImpact
Change-Id: I3238eafcf2fde0cb4fa6cd48099908980c28d39f
This profile will be applied to the DHCP ports if the DHCP service
is enabled.
The change remove the requirement that the admin create this out of
band.
This is now possible due to the fact that we are using a distributed
locking mechanism.
Change-Id: I12538af5849226ae3d8aeaea94bdd80be6ed0605
A new config parameter is introduced in nsx.ini to add the UUID
of the switching profile which will enable DHCP traffic. This profile
will be applied on DHCP ports only, overriding any switch profiles
applied on the backend. This profile must be configured in nsx.ini
if Neutron's DHCP service is to be used.
This profile must be created, out of band, on the NSX backend with
DHCP Server and Client Block disabled.
DocImpact
Change-Id: Iffeead83cbf58e106a284e1b1b142a360eb6dd40
Allows user to specify default exclusive_router_appliance_size in
nsx.ini file. If --router-size isn't specified in neutron router-create CLI
command; exclusive_router_appliance_size will be picked up
DocImpact
Change-Id: I010bfdb8c5807bb933085f049326082c8b5782dc
Currently the nsx_l2gw_driver option exists in the base_opts in
config, which mostly belongs to NSX-MH. This patch proposes to move
it under DEFAULT section.
Change-Id: I0884f420debe14355d8bc0cf66ff2a418b2d4d78
This patch will create:
vmware_nsx/services/common for common plugin files
vmware_nsx/services/nsx_v3 for nsx_v3 specific plugin files
This is part of new vmware_nsx directory structure proposed in
https://goo.gl/GdWXyH.
Change-Id: I30753aef1c06e2a1b15d336e1d661f3b44ea669e
This patch adds the backend driver to support Layer 2 gateway
API calls for NSXv3.
Change-Id: Iec1e143115579cca6c8158188217ead4209959bd
Partial-bug: #1481087
The directory contains files which belong in neutron
Currently excluding etc/policy.json since its required by unittests,
it would be also removed once https://review.openstack.org/#/c/145535/ merged.
Change-Id: Iec3ac2234472431437b15c475986efa82852aa2f
Signed-off-by: Roey Chen <roeyc@vmware.com>
Rename class NsxvSectionMapping to NsxvSecurityGroupSectionMapping,
to satisfy neutron model review feedback
Also update test-requirements to refer to neutron repo
Change-Id: I7e4ca7985f4dd2c755a026058690b5767fe06b76
Akihiro Motoki