Group Tags#

Micro Segmentation → GTGroup Tags

A GroupTag is used to create micro segments in the network, tagging endpoints with a similar security posture, allowing for easy management of security rules. Group tags can be assigned to BridgeInterfaces, RoutedInterfaces, IRBInterfaces, VLANs, and StaticRoutes through a GroupTagAssociationPolicy

Scopes#

GroupTags are uniquely identified by a "Group Tag ID" which is automatically assigned by EDA and is used by the node to distribute the GroupTags through the control plane. The Group Tag IDs are allocated from predefined IndexAllocationPools bootstrap resources named group-tag-pool-global and group-tag-pool-local.

Because there is a limited range from which to assign "Group Tag IDs", EDA introduces a concept of local and global "scopes" where an ID is uniquely defined. Scopes can be either global (the whole namespace) or local (the Virtual Network or highest level service abstraction used, for example, a Router or BridgeDomain).

Global scope#

A global scope is only recommended when

• GroupTags are leaked between different services (for example shared infrastructure such as DNS, storage, NTP, etc)
• A service is manually composed of individual service abstractions such as a Router or BridgeDomain etc.

If a GroupTag is created with a global scope, the "Group Tag ID" is reserved in the group-tag-pool-global IndexAllocationPool. The ID is reserved within the namespace before association, at the time of creation.

For example: a global GroupTag is assigned ID 11; this ID is reserved in all services of the namespace.

Local scope#

A local GroupTag can have different IDs in different scopes. If a GroupTag is created with a local scope a "Group Tag ID" will be reserved in an instance of the group-tag-pool-local IndexAllocationPool for each scope where the GroupTag is used.

For example a GroupTag "blue" is created with a local scope and GroupTag "blue" is associated with a BridgeInterface in VirtualNetwork Service-1, an ID (e.g. 64) will be allocated from a group-tag-pool-local instance dedicated to Service-1. When "blue" is associated with an interface or route in another VirtualNetwork Service-2, an ID (e.g. 92) will be allocated from a group-tag-pool-local instance dedicated to Service-2. The GroupTag "blue" can have different IDs in different scopes depending on the availability of indices in the pool instance.

Dependencies#

The IndexAllocationPool resources named group-tag-pool-global and group-tag-pool-local are required in order for a "Group Tag ID" to be allocated for the GroupTag. They are created during namespace bootstrapping or can be created manually.

Referenced resources#

There are no references to other resources.

Examples#

apiVersion: microsegmentation.eda.nokia.com/v1alpha1
kind: GroupTag
metadata:
  namespace: eda
  name: quarantine
spec:
  scope: Local

cat << 'EOF' | kubectl apply -f -
apiVersion: microsegmentation.eda.nokia.com/v1alpha1
kind: GroupTag
metadata:
  namespace: eda
  name: quarantine
spec:
  scope: Local
EOF

Custom Resource Definition#

To browse the Custom Resource Definition go to crd.eda.dev.