Security Policies
SUMMARY Starting in CN2 Release 23.1, CN2 supports Namespace Security Polices. Namespace policies allows you to define security polices from endpoints within a namespace, or to an external IP address.
Namespace Security Policies
- Overview of Namespace Security Policies
- Policy Priority: Namespace Security Polices and Kubernetes Network Policies
- Example of a Namespace Security Policy
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:
Rule: Allow Src: (174.16.10.0/16 except 174.16.10.40/28) (174.16.10.40/24 except 174.16.10.70/32}) Dst: (175.16.10.0/24 except 175.16.10.40/32) (175.16.10.0/24 except 175.16.10.70/32)) port:[9000:9010])
-
Namespace security policies support two actions:
pass
anddeny
. The default action isdeny
. 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.
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. Therules
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
oripBlock
). -
DstEP
: List of destination endpoints for a rule match criteria (podSelector
oripBlock
). -
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
ordeny
). The default action isdeny
.
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.
All Namespace security policies are user-defined.
Each policy is prioritized, as follows:
-
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.
-
Namespace Security Policies (Allow): If you do not define a policy in CN2, traffic is allowed between all pods in the corresponding namespace.
-
Kubernetes Network Polices: By default, a Kubernetes network policy allows traffic from all sources.
-
Default (Deny): If a pod does not match any Kubernetes network policies, traffic is denied.
![Policy Priority: Namespace Security Polices and Kubernetes Network Policies](../../images/jn-000529.png)
Example of a Namespace Security Policy
Here is an example of a namespace security policy:
When you create a namespace security policy, you only need to provide the
namespace and the source and destination endpoints
(namespace
, podSelector
,
ipBlock
).
apiVersion: core.contrail.juniper.net/v3 kind: NamespaceSecurityPolicy metadata: name: allow-hr11-to-fac12 namespace: ns-svl spec: rules: - srcEP: endPoints: - podSelector: matchLabels: dept: hr matchExpressions: - {key: tier, operator: In, values: [one]} - ipBlock: cidr: 174.19.12.11/32 dstEP: endPoints: - podSelector: matchLabels: dept: fac - ipBlock: cidr: 174.19.12.12/32 ports: - protocol: TCP port: 3300 endPort: 3400 action: pass
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.
Source | Destination |
---|---|
Pod with label dept:hr to: |
|
ipBlock174.19.12.11/32 to: |
|