Difference between revisions of "Blueprint-ipam-extensions-for-neutron"
Rudrarugge (talk | contribs) (→IPAM Resource) |
Rudrarugge (talk | contribs) (→Network Policy Example) |
||
Line 33: | Line 33: | ||
|} | |} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Network Policy and FWaaS== | ==Network Policy and FWaaS== | ||
Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way | Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way |
Revision as of 00:31, 8 October 2013
Contents
IPAM Overview
Information common to a set of subnets on a network will be present in this resource. Following information will be stored in the resource:
- Address allocation scheme (DHCP or unmanaged)
- DNS server information
- CIDR to be used by the network (in which all subnet definitions should belong)
- List of DHCP option, value tuples
IPAM Resource
Network policy is mechanism by which a declarative way is provided to the clients to decided how Neutron virtual networks are connected and what traffic is allowed over those connections. Clients do not have to worry about how exactly the connectivity is achieved and how/where the rules are applied. This is to simplify deployments of multitier applications
Attribute | Type | Required | CRUD | DefaultValue | Validation Constraint | Notes |
---|---|---|---|---|---|---|
id | uuid-str | N/A | R | generated | N/A | UUID for ipam object |
tenant_id | uuid-str | Yes | CR | None | valid tenant_id | UUID of the tenant for ipam |
name | string | no | CRU | None | N/A | name of the ipam resource |
fq_name | string | no | CRU | None | N/A | fully qualified name of the ipam object |
ipam_method | string | no | CRU | None | N/A | dhcp or fixed assignment |
ipam_dns_method | string | no | CRU | None | N/A | default, tenant or virtual dns server |
ipam_dns_addr | string | no | CRU | None | N/A | dns server address or name |
dhcp_options | list[string-string] | no | CRU | None | list or key-val pairs | list of dns key-value pairs |
cidr_block | list[string] | no | CRU | None | list of cidrs | list of cidr blocks |
Network Policy and FWaaS
Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way
- pass front-end any <> back-end any any apply-service Firewall_instance_1
Network Policy and Security Groups
Network policy is not replacement for security groups either. Security groups are protecting the interfaces to VM(s). Network policy is between virtual networks. Have policies at various levels actually increases flexibility and reduces need for NxN matrix like rule explosion.
Network Policy Bind Points
In traditional networking gear ACL were always applied at various levels.
- Ports ACL(s) à Security groups
- VLAN ACL(s) and Router ACL(s) à network policy
Network policy can be expressed in terms of network ID(s) rather than IP prefixes (CIDRs)
Information given in such a resource can be used to derive
- Connectivity between networks. i.e whether at a L3 network level routes need to be exchanged. e.g. allow traffic from web-network to db-network.
- Packet filters on traffic crossing two networks. e.g. allow only mysql traffic between web-network to db-network
CLI for Network Policy
policy-create Create a policy for a tenant. policy-delete Delete a given policy. policy-list List policy(s) that belong to a given tenant. policy-show Show information of a given policy. policy-update Update a given policy. policy-rule-create Create a policy rule in a policy. policy-rule-delete Delete a policy rule from a policy. policy-rule-update Update policy rule in a policy. policy-rule-show Show information of a policy rule.
REST APIs
Policy REST APIs
GET /v1.0/policies/ GET /v1.0/policies/policy-id POST /v1.0/policies UPDATE /v1.0/policies/policy-id DELETE /v1.0/policies/policy-id
PolicyCreate
JSON Request
{ "policy": { "tenant_id": "310df60f-2a10-4ee5-9554-98393092194c", "name": "test_policy", } }
JSON Response
{ "vpnservice": { "id": "02b1fef7-16f5-4917-bf19-c40a9af805ed", "tenant-id": "310df60f-2a10-4ee5-9554-98393092194c", "name": "test_policy", } }
Polcy Rules REST APIs
GET /v1.0/policy-rules/ GET /v1.0/policy-rules/policy-rule-id POST /v1.0/policy-rules UPDATE /v1.0/policy-rules/policy-rule-id DELETE /v1.0/policy-rules/policy-rule-id
PolicyRuleCreate
JSON Request
{ "policy_rule": { "policy_id": "04c77d28-f93d-4405-8b1a-d25b35e05037", "direction": "ingress", "protocol": "6", "src_addresses": ["1.1.1.0/24", "2.2.2.0/24"], "src_ports": ["10000-10100", "10500-10700"], "dst_addresses": ["1.1.1.0/24", "2.2.2.0/24"], "src_ports": ["80-80"], "action_list": ["simple_action-pass"], } }
JSON Response
{ "policy_rule": { "id": "f3dae1c4-e6f8-4165-ae1f-e20408b04fe2", "policy_id": "04c77d28-f93d-4405-8b1a-d25b35e05037", "direction": "ingress", "protocol": "6", "src_addresses": ["1.1.1.0/24", "2.2.2.0/24"], "src_ports": ["10000-10100", "10500-10700"], "dst_addresses": ["1.1.1.0/24", "2.2.2.0/24"], "src_ports": ["80-80"], "action_list": ["simple_action-pass"], } }
Policy Workflow
- Policy create
- Policy rule add
- Neutron Network APIs to attach one or more policies in certain order.