Add ClusterGroup CRD to group Pods based on labels or share IPBlock

[abhiraut]

Describe what you are trying to solve
Currently Antrea policies are responsible to specify the security rules that apply to workloads and also responsible to specify how to group the source and destination and the workloads to which the rules apply to. This grouping of workloads is done via the use of resource selectors (podSelector, namespaceSelector...) which has the capabilities of grouping resources by matching labels or expressions on those labels. In case the labels on the workloads are updated, user must go and update each and every policy to update those labelSelectors. Here we propose to separate the function of grouping of workloads from the security aspect of policy. Adding another level of indirection allows users to update grouping membership without having to update individual policy rules. The same applies to sharing of IPBlocks among ACNPs.

Describe the solution you have in mind
Introduce a new CRD to group and share Pods or IPBlock. The group workers can then independently sync the members for the ClusterGroup. These ClusterGroups can be referenced in the AppliedTo and ingress/egress rules of an Antrea ClusterNetworkPolicy in place of stand-alone labelSelectors. Any change in the selector or the IPBlock, can be changed in one place and then reflected in all the affected ClusterNetworkPolicies.

In addition to ClusterNetworkPolicies, these ClusterGroups can be referenced elsewhere in other CRDs as well.

Describe how your solution impacts user flows
Users are expected to create ClusterGroups to group workloads to which they intend to apply policies to. Once the CG are created, users must reference them in ClusterNetworkPolicies in place of stand alone selectors.
Users can continue using the stand alone selectors in policies, but they cannot use both a CG and stand alone selectors in a single ClusterNetworkPolicy.

Describe the main design/architecture of your solution
A CG CRD may look like below:

apiVersion: "core.antrea.tanzu.vmware.com/v1alpha2"
kind: ClusterGroup
metadata:
    name:       server-group
spec:
    podSelector:                        // Select Pods from all Namespaces. Selects Pods from selected Namespaces if set with namespaceSelector.
        matchLabels:
        matchExpressions:  
    namespaceSelector:      {}          // Select all Pods from Namespaces selected by this selector. If set with pod, selects specific Pods
                                        // Namespaces selected by this selector.
itself.
    ipBlocks:                           // Specify the IP blocks in CIDR format. Cannot be set with other selectors.
        - cidr: 10.0.10.0/24
        - cidr: 192.168.24.0/28
status:
    phase: Pending|Realized  // High-level summary describing the status of a ClusterGroup.

IPBlock cannot be set with PodSelector/NamespaceSelector.

The CG resource will support a Status sub resource to determine the overall status of the CG i.e. whether it has realized GroupMembers or still in Pending state.

In addition to the Status, antrea-controller will also expose group-membership and group-association APIs.

• The group-membership API will return the members of the group corresponding to a given CG

# curl <k8s-apiserver>:8001/apis/controlplane.antrea.tanzu.vmware.com/v1beta2/clustergroupmembers/test-cg
{
  "kind": "GroupMemberList",
  "apiVersion": "controlplane.antrea.tanzu.vmware.com/v1beta2",
  "metadata": {
    "selfLink": "/apis/controlplane.antrea.tanzu.vmware.com/v1beta2/clustergroupmembers/test-cg",
    "creationTimestamp": null
  },
  "effectiveMembers": [
    {
      "pod": {
         "name": "pod1",
         "namespace": "ns1",
       }
       "ips": [
          "AAAAAAAAAAAAAP//CgoBBg=="
       ]
       "ports": [
        {
          "port": 8080,
          "name": "secured",
          "protocol": "TCP"
        }
      ]
    },
  ]
}

• The group-association query will return the groups associated with the input Pod.

# curl <k8s-apiserver>:8001/apis/controlplane.antrea.tanzu.vmware.com/v1beta2/namespaces/ns1/groupassociations/pod1
{
  "kind": "GroupAssociation",
  "apiVersion": "controlplane.antrea.tanzu.vmware.com/v1beta2",
  "metadata": {
    "selfLink": "/apis/controlplane.antrea.tanzu.vmware.com/v1beta2/namespaces/ns1/groupassociations/pod1",
    "creationTimestamp": null
  },
  "associatedGroups": [
    {
      "name": "test-cg",
      "uid": "d0506e0a-f4b0-4e0c-bb4d-ee9d0bcc9b09"
    }
  ]
}

• ClusterGroup API types Add ClusterGroup API types #1639
• ClusterGroup validation webhook Add ClusterGroup API types #1639
• controller updates to group members Add ClusterGroup API types #1639
• ClusterGroup reference in ACNP AppliedTo Add ClusterGroup reference in ClusterNetworkPolicy AppliedTo #1750
• ClusterGroup reference in ACNP AddressGroup Add ClusterGroup reference in ClusterNetworkPolicy rules #1734
• ClusterGroup group-membership API Add ClusterGroup Membership and Association query API #1688
• ClusterGroup group-association API Add ClusterGroup Membership and Association query API #1688
• ClusterGroup Status subresource Add Status subresource to ClusterGroup CRD #1778
• ServiceReference in ClusterGroup
• ExternalEntitiesSelector in ClusterGroup
• Documentation
• e2e tests

[abhiraut]

All related PRs have been merged. Mark it closed.