ACNP: replace NamespaceSelector with Namespaces for policy peers

[Dyanngg]

Describe what you are trying to solve
Users want to reduce the management overhead of security policies by writing succinct Antrea-native policies. For example, a namespace isolation policy for the entire cluster (inter-ns deny, intra-ns allow), currently users must create a default-allow policy per Namespace instead of a single Cluster scoped policy. This is due to the fact that the ACNP is not expressive enough to satisfy the above use case.

Describe the solution you have in mind
Introduce a new Namespaces field which replaces NamespaceSelector in Antrea ClusterNetworkPolicy peers:

type Namespaces struct {
	Self      bool
	Selector  *metav1.LabelSelector 
}

Namespaces.Selector will have the exact same semantics as the original NamespaceSelector. Self, on the other hand, is a new optional field, which evaluates to false by default. When self: true is set, no selectors can be present concurrently. This is a special keyword to indicate that the corresponding podSelector should be evaluated from the Namespace for which the ingress/egress rule is currently being evaluated upon. Consider the following exmaple:

• Pods [a1, b1] exist in Namespace x, which has labels app=a and app=b respectively.
• Pods [a2, b2] exist in Namespace y, which also has labels app=a and app=b respectively.

apiVersion: security.antrea.tanzu.vmware.com/v1alpha2
kind: ClusterNetworkPolicy
spec:
  appliedTo:
  - namespaceSelector: {}
  ingress:
    - from:
      action: Deny
      - namespaces:
          self: true
        podSelector:
          matchLabels:
            app: b

The above ClusterNetworkPolicy should be interpreted as: for each Namespace in the cluster, all Pods in that Namespace should only allow traffic from Pods in the same Namespace who has label app=b. Hence, the policy above denies x/b1 -> x/a1 and y/b2 -> y/a2, but does not regulate y/b2 -> x/a1 and x/b1 -> y/b2.

Using the new semantics, one can easily write a single Namespace isolation ACNP as follows:

apiVersion: "security.antrea.tanzu.vmware.com/v1alpha2"
kind: ClusterNetworkPolicy
metadata:
    name: ns-isolation
spec:
    tier: baseline
    priority: 5
    appliedTo:
    // Select all Namespaces
    - namespaceSelector: {}
    ingress:       
    - from: 
      // Allow ingress traffic from all Pods from AppliedTo Pod's own Namespace                          
      action: Allow
      - namespaces:
           self: true
         podSelector: {}
    - from: 
      // Deny ingress traffic from all Pods from all Namespaces
      action: Deny
      -  namespaces:
           selector: {}
         podSelector: {}

Since the allow rule allows intra-namespace traffic and comes before the deny rule to deny all ingress traffic, the intra-namespace traffic will be allowed and any other traffic will be dropped by the deny rule.

Describe how your solution impacts user flows
The ACNP apiVersion will be bumped up to v1alpha2 and older policies will be internally converted to this new semantics by automatically translating NamespaceSelector to Namespaces.Selector. Users must now be informed of the new semantics and start using v1alpha2 version of the policies.

Test plan
In addition to e2e and unit tests, upgrade tests must be added to ensure smooth upgrade workflows.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment, or this will be closed in 180 days