Developer Documentation


Contains ordered list of Rules for GatewayPolicy


Required Property Name Type Description
optional _create_time integer

Timestamp of resource creation

optional _create_user string

ID of the user who created this resource

optional _last_modified_time integer

Timestamp of last modification

optional _last_modified_user string

ID of the user who last modified this resource

optional _links array of ResourceLink

The server will populate this field when returing the resource. Ignored on PUT and POST.

optional _protection string

Protection status is one of the following: PROTECTED - the client who retrieved the entity is not allowed to modify it. NOT_PROTECTED - the client who retrieved the entity is allowed to modify it REQUIRE_OVERRIDE - the client who retrieved the entity is a super user and can modify it, but only when providing the request header X-Allow-Overwrite=true. UNKNOWN - the _protection field could not be determined for this entity.

optional _revision integer

The _revision property describes the current revision of the resource. To prevent clients from overwriting each other’s changes, PUT operations must include the current _revision of the resource, which clients should obtain by issuing a GET operation. If the _revision provided in a PUT request is missing or stale, the operation will be rejected.

optional _schema string

Schema for this resource

optional _self SelfResourceLink

Link to this resource

optional _system_owned boolean

Indicates system owned resource

optional category string
  • Distributed Firewall - Policy framework provides five pre-defined categories for classifying a security policy. They are “Ethernet”,“Emergency”, “Infrastructure” “Environment” and “Application”. There is a pre-determined order in which the policy framework manages the priority of these security policies. Ethernet category is for supporting layer 2 firewall rules. The other four categories are applicable for layer 3 rules. Amongst them, the Emergency category has the highest priority followed by Infrastructure, Environment and then Application rules. Administrator can choose to categorize a security policy into the above categories or can choose to leave it empty. If empty it will have the least precedence w.r.t the above four categories.
  • Edge Firewall - Policy Framework for Edge Firewall provides six pre-defined categories “Emergency”, “SystemRules”, “SharedPreRules”, “LocalGatewayRules”, “AutoServiceRules” and “Default”, in order of priority of rules. All categories are allowed for Gatetway Policies that belong to ‘default’ Domain. However, for user created domains, category is restricted to “SharedPreRules” or “LocalGatewayRules” only. Also, the users can add/modify/delete rules from only the “SharedPreRules” and “LocalGatewayRules” categories. If user doesn’t specify the category then defaulted to “Rules”. System generated category is used by NSX created rules, for example BFD rules. Autoplumbed category used by NSX verticals to autoplumb data path rules. Finally, “Default” category is the placeholder default rules with lowest in the order of priority.
optional children array of ChildPolicyConfigResource

subtree for this type within policy tree containing nested elements.

optional comments string

Comments for security policy lock/unlock.

optional description string

Description of this resource

optional display_name string

Defaults to ID if not set

optional id string

Unique identifier of this resource

optional lock_modified_by string

ID of the user who last modified the lock for the secruity policy.

optional lock_modified_time integer

SecurityPolicy locked/unlocked time in epoch milliseconds.

optional locked boolean

Indicates whether a security policy should be locked. If the security policy is locked by a user, then no other user would be able to modify this security policy. Once the user releases the lock, other users can update this security policy.

optional marked_for_delete boolean

Intent objects are not directly deleted from the system when a delete is invoked on them. They are marked for deletion and only when all the realized entities for that intent object gets deleted, the intent object is deleted. Objects that are marked for deletion are not returned in GET call. One can use the search API to get these objects.

optional parent_path string

Path of its parent

optional path string

Absolute path of this object

optional relative_path string

Path relative from its parent

optional resource_type string

The type of this resource.

optional rules array of Rule

Rules that are a part of this SecurityPolicy

optional scope array of string

The list of group paths where the rules in this policy will get applied. This scope will take precedence over rule level scope. Supported only for security policies.

optional sequence_number integer

This field is used to resolve conflicts between security policies across domains. In order to change the sequence number of a policy one can fire a POST request on the policy entity with a query parameter action=revise The sequence number field will reflect the value of the computed sequence number upon execution of the above mentioned POST request. For scenarios where the administrator is using a template to update several security policies, the only way to set the sequence number is to explicitly specify the sequence number for each security policy. If no sequence number is specified in the payload, a value of 0 is assigned by default. If there are multiple policies with the same sequence number then their order is not deterministic. If a specific order of policies is desired, then one has to specify unique sequence numbers or use the POST request on the policy entity with a query parameter action=revise to let the framework assign a sequence number

optional stateful boolean

Stateful or Stateless nature of security policy is enforced on all rules in this security policy. When it is stateful, the state of the network connects are tracked and a stateful packet inspection is performed. Layer3 security policies can be stateful or stateless. By default, they are stateful. Layer2 security policies can only be stateless.

optional tags array of Tag

Opaque identifiers meaningful to the API user

optional tcp_strict boolean

Ensures that a 3 way TCP handshake is done before the data packets are sent. tcp_strict=true is supported only for stateful security policies.


Was this page helpful?