Custom security policies can be applied to virtual machines with labels, and virtual machines, IP addresses, or Pods (using the AIC) included in security groups. For a virtual machine, the virtual distributed switch to which the virtual machine's VM network belongs must be associated with the ANS service; for a Pod, the virtual distributed switch to which the VM network of the AIC-dedicated NIC on the virtual machine node hosting the Pod belongs must also be associated with the ANS service. A virtual machine cannot be used as a policy object if none of the virtual distributed switches for its VM networks is associated with the ANS service that the policy belongs to.
Custom security policies support two policy types, which are configured when the policy is created.
Allow policy
An allow policy permits only trusted traffic through the firewall. Once an allow policy is applied to a policy object, all traffic other than what the policy explicitly specifies is blocked. This strict control mechanism ensures that only authorized traffic enters the system, significantly improving security.
Deny policy
A deny policy blocks specific traffic. Unlike an allow policy, a deny policy blocks only the traffic explicitly specified in the policy; whether other traffic is permitted depends on other security policies in the system. Deny policies offer a simple, flexible way to efficiently control and respond to known security threats without changing how other traffic is handled by other security policies.
If a strict quarantine or forensic quarantine policy is also applied to a virtual machine, the custom security policy is overridden, and only the strict quarantine or forensic quarantine policy applies.
The policy objects of a custom security policy can be dynamically updated through the mapping of security groups or virtual machine labels to virtual machines, and the mapping of security groups to Pods.
Virtual machine labels can be configured on the AOC management platform. Once a label is applied to a virtual machine, the ANS distributed firewall dynamically groups virtual machines by label. Once the virtual machines associated with a label change, for example, when new workloads come online, you only need to assign the corresponding label to the new virtual machines, and the system will automatically generate the relevant security policies and security rules.
Security groups can be configured in the ANS service. Security groups are categorized by member type into VM security groups, IP security groups, and Pod security groups. VM security groups can include label combinations as dynamic members or specific virtual machines as static members. To apply the same security policy to virtual machines running a particular workload, add them to the same security group and use the security group as the policy object in the relevant policies. IP security groups accept IP addresses as members. Pod security groups use the configured workload cluster, Kubernetes namespace, and Pod labels to select Pods as dynamic members.
Information:
- When adding policy objects using virtual machine labels, you can select one or more labels. When multiple labels are selected, the filtering logic is AND: Only virtual machines associated with all selected labels are included.
- You can simultaneously add multiple policy object groups using both virtual machine labels and security groups. For example, one policy object group can be added via a security group and another via a virtual machine label. Multiple policy object groups are combined with OR logic: Any virtual machine included in any policy object group becomes a policy object of this custom security policy and has the associated security rules applied.
- When an IP security group is used as a policy object, the policies related to that IP are pushed to all nodes across all associated clusters.
Security rules support multiple object types: virtual machines, Pods, IP addresses, CIDR blocks, and IP address ranges. Rules are divided into ingress rules and egress rules. You can use security rule objects to flexibly define the ingress and egress rules for policy objects.
Security rules support the TCP, UDP, ICMP, and IPIP protocols, as well as dynamic protocols FTP and TFTP. For TCP and UDP, you can specify ports or port ranges.
Different types of security rules are defined based on the selected policy type:
Allowlist rules
If the policy is an allow policy, security rules are defined as an allowlist: Only the ingress and egress traffic specified in the allowlist is permitted, and all other traffic is blocked by default.
Blocklist rules
If the policy is a deny policy, security rules are defined as a blocklist: the ingress and egress traffic specified in the blocklist is blocked, while all other traffic is unaffected. Whether that traffic is permitted depends on other security policies.
The core mechanism of symmetric policies is to configure symmetric rules for allowlist objects, ensuring bidirectional communication between the allowlist and a policy object. For example, for virtual machine A to access virtual machine B, an egress rule allowing traffic to B must be configured on A, and an ingress rule allowing traffic from A must be configured on B; only then can normal communication take place between them. In this case, the egress rule on virtual machine A and the ingress rule on virtual machine B together form a symmetric policy.
In a custom security policy (allow policy), if ingress and egress allowlists are configured for a policy object, the ANS distributed firewall sets up an ingress rule for the policy object based on the ingress allowlist, permitting traffic from all virtual machines and Pods in the allowlist, and an egress rule based on the egress allowlist, permitting traffic to be sent to those in the egress allowlist. To ensure that the ingress and egress allowlists take effect, symmetric policies must also be configured for the virtual machines and Pods in the allowlists. The method for configuring symmetric policies varies depending on how the allowlists were set up, as described below:
Adding allowlist entries using virtual machine labels, VM security groups, or Pod security groups
With this method, since the virtual machines and Pods associated with the labels or security groups are all within the scope managed by the ANS service, the ANS service automatically configures symmetric policies for the virtual machines and Pods in the allowlist, ensuring that the allowlist takes effect.
Adding allowlist entries using IP security groups or IP addresses
When adding an allowlist entry using IP security groups or IP addresses, if the IP address is within the scope managed by the ANS service, you can choose whether to configure a symmetric policy for the allowlist. If you choose not to, only the relevant rules are configured for the policy object, and how the actual traffic is handled will depend on other security policies associated with the virtual machines and Pods in the allowlist.
If the IP address is outside the scope managed by the ANS service, ANS cannot configure a symmetric policy for that IP address.
The table below shows several examples of custom security policies.
| Custom security policy | Policy type | Apply to | Ingress rule | Egress rule |
|---|---|---|---|---|
| App-Service-Policy | Allow policy | App | Object: Web Protocol: TCP Ports: 6000 |
Object: DB Protocol: TCP Ports: 8000 |
| Web-Service-Policy | Allow policy | Web | Object: Client Protocol: TCP Ports: 80 |
Object: App Protocol: TCP Ports: 6000 |
| Linux-VM-Policy | Deny policy | VM-Linux | Object: VM-Others, 192.168.11.10 Protocol: UDP Ports: 10000 ~ 10100 |
Object: 192.168.10.0/24 Protocol: ICMP |
| VM-Pod-Policy | Allow policy | Pod-Group | Object: VM-App, 192.168.11.10 Protocol: UDP Ports: 10000 ~ 10100 |
Object: Pod-Web Protocol: ICMP |
