Tag Based Security Policy¶
Aviatrix gateway security policies are implemented at each gateway, key features are:
- It is a L4 stateful firewall that filters on CIDR, protocol and port.
- Each policy is associated with “Allow” or “Deny” action.
- A Base policy for “Allow” or “Deny” for the gateway can be used as a catch all rule.
- All security policy events as well as packets can be logged to Splunk, SumoLogic, Syslog, ELK and Datadog.
Starting with release 3.0, a tag mechanism has been introduced to make the security policy specification more user friendly. You can associate an IP address or a subnet with a name tag and use it as a shorthand to specify the source and destination for your security rules.
1. Define a Tag¶
You give a tag a name and a list of one or more network addresses. The network address can be a subnet or a host IP address. Security -> Stateful Firewall -> Tag Management -> Add New
A tag is a global resource to the Aviatrix Controller and can be applied to any gateway.
2. Edit a Tag¶
Once a tag is created, you can edit the tag.
Editing is about adding a name to a CIDR address (network address or host address). Multiple Name<->CIDR pair can be added. When you are done Editing, click Update to take effect.
3. Apply Policy¶
Click Security -> Stateful Firewall -> Policy
You should see a list of gateways that the Controller manages. Highlight a gateway and click Edit.
To configure security policies, select a Base Policy. Base Policy is always attached as the last rule as a catch all policy.
Select Enable Packet Logging if you want to forward logs to well known log management systems, such as Splunk, Sumo Logic, Elastic Search and remote syslog.
If you click Add New, you can specify Source by manually entering a specific CIDR; you can also click the table icon to select one of the tags you created earlier.
Both Source and Destination can be configured either manually or by using tags. Once a rule is “Saved”, you must remember to click Update for the policy to take effect.
Note: For the Destination field, if a host name is specified either manually or with a tag, the IP address of the host name will be resolved when programming the security policy. A host name is not suitable if it is a public web site, such as www.google.com. To filter on public host names, refer to FQDN Whitelists.
5. Example Use Case¶
Say you have a group of EC2 instances or a group of AWS Workspace instances. You would like to set up policies to allow them to access a database which itself consists of a group of nodes.
You can create a tag, name it my-app and configure the list of IP addresses associated with each instance with a name. You can then create a second tag, name it my-database, and configure the list of IP addresses associated with each instance with a name.
You then can simply apply one policy at the gateway that says my-app to my-database is allowed. The Controller will automatically push the policies to the gateway.