Security Policies

Overview of Namespace Security Policies

CN2 supports Kubernetes network policies to control flow of traffic to and from Kubernetes workloads to other Kubernetes workloads or IP addresses. Kubernetes network policies are developer-centric policies where a developer decides which traffic is allowed in and out of their workloads.

Although Kubernetes network policies are useful in restricting the communication between pods in a namespace, you can only control ingress and egress traffic from a selected set of pods. As an administrator, these policies can be complex to use, specifically if you are interested in end-to-end traffic flow based on application or security requirements.

For end-to-end traffic flow, CN2 supports namespace security policies. Namespace security policies are administrative-centric policies. These policies allows you to define polices from a source endpoint to a destination endpoint within a namespace. With Namespace security policies, you can allow or deny traffic between pods in a namespace or to an external IP address.

Namespace security policies have the following characteristics:

• You can only define security polices within a namespace. By default, security policies can only manage traffic within its own namespace.

• When you define a security policy, the policy is applied on all pods in a namespace.

• By default, if a pod does not match any user-defined policies, traffic is denied.

• You define security policies within a namespace using rules. Each rule has a source endpoint and destination endpoint. For ease of use, the security polices use the same endpoints as Kubernetes network policies (namespace, podselector, IPblock).

• Namespace security polices can contain one or multiple rules. For example:

• Namespace security policies support two actions: pass and deny. The default action is deny. Actions are per-policy, not per rule. This means that any rules you define follows the same action.

• For each rule, you can define the destination ports or destination port range (combination of source, destination, and port). For example, let's say you want particular IP address or source to access the server on a specified destination port or range of ports.

Note:

Namespace security polices only support IPv4 IP addresses.

A Namespace security policy consists of the following sections:

• Spec

  The spec field contains the rules and actions you need to define a security policy. The rules contain a list of user defined source and destination matches.

  The rules are categorized, as follows:

  • SrcEP: List of source endpoints for a rule match criteria (podSelector or ipBlock).

  • DstEP: List of destination endpoints for a rule match criteria (podSelector or ipBlock).

  • Ports: List of destination ports to be matched for this rule (contains a combination of ports and protocol).

• Action: Action to be taken if any policy rule matches (pass or deny). The default action is deny.

To see an example of a security policy, see Example of a Namespace Security Policy.

Policy Priority: Namespace Security Polices and Kubernetes Network Policies

Because CN2 uses both Kubernetes network polices and namespace security policies, we use a sequence to determine how rules are processed between the two different policies.

Figure 1 shows how Kubernetes network policies along with namespace security policies are prioritized. The rules for namespace security polices are prioritized first, followed by Kubernetes network policies.

Note:

All Namespace security policies are user-defined.

Each policy is prioritized, as follows:

1. Namespace Security Policies (Deny): By default, if a pod does not match any policies in CN2, traffic is denied. The deny policies are given a higher priority over the allow policies.

2. Namespace Security Policies (Allow): If you do not define a policy in CN2, traffic is allowed between all pods in the corresponding namespace.

3. Kubernetes Network Polices: By default, a Kubernetes network policy allows traffic from all sources.

4. Default (Deny): If a pod does not match any Kubernetes network policies, traffic is denied.

Example of a Namespace Security Policy

Here is an example of a namespace security policy:

Note:

When you create a namespace security policy, you only need to provide the namespace and the source and destination endpoints (namespace, podSelector, ipBlock).

In this example, we defined a security policy in namespace: ns-svl. In this policy, we've created a combination of rules for the source and destination endpoints. Table 1 describes the different combinations.

For example, any traffic generated from the source (podSelector or iBlock) to the destination (podSelector or ipBlock) is allowed. The remaining traffic in the namespace is denied.

We've also specified the destination ports 3300 and 3400. This allows TCP traffic between the destination ports and between the source and destination endpoints.

Table 1: Example: Source and Destination Combinations

Source	Destination
Pod with label dept:hr to:	Pod with label dept:fac or destination (dstEP). Or, ipBlock cidr:174.19.12.12/32.
ipBlock174.19.12.11/32 to:	Pod with label dept:fac or destination (dstEP). Or, ipBlock: cidr:174.19.12.12/32.