Skip to main content

Global network policy

A global network policy resource (GlobalNetworkPolicy) represents an ordered set of rules which are applied to a collection of endpoints that match a label selector.

GlobalNetworkPolicy is not a namespaced resource. GlobalNetworkPolicy applies to workload endpoint resources in all namespaces, and to host endpoint resources. Select a namespace in a GlobalNetworkPolicy in the standard selector by using as the label name and a namespace name as the value to compare against, e.g., == "default". See network policy resource for namespaced network policy.

GlobalNetworkPolicy resources can be used to define network connectivity rules between groups of Calico Cloud endpoints and host endpoints.

GlobalNetworkPolicies are organized into tiers, which provide an additional layer of ordering—in particular, note that the Pass action skips to the next tier, to enable hierarchical security policy.

For kubectl commands, the following case-insensitive aliases may be used to specify the resource type on the CLI:, and abbreviations such as globalnetworkpolicy.p and globalnetworkpolicies.p.

Sample YAML

This sample policy allows TCP traffic from frontend endpoints to port 6379 on database endpoints.

kind: GlobalNetworkPolicy
name: internal-access.allow-tcp-6379
tier: internal-access
selector: role == 'database'
- Ingress
- Egress
- action: Allow
from: frontend
to: database
protocol: TCP
selector: role == 'frontend'
- 6379
- action: Allow



FieldDescriptionAccepted ValuesSchemaDefault
nameThe name of the network policy. Required.Alphanumeric string with optional ., _, or -.string


FieldDescriptionAccepted ValuesSchemaDefault
orderControls the order of precedence. Calico Cloud applies the policy with the lowest value first.float
tierName of the tier this policy belongs to.stringdefault
selectorSelects the endpoints to which this policy applies.selectorall()
serviceAccountSelectorSelects the service account(s) to which this policy applies. Select all service accounts in the cluster with a specific name using the label.selectorall()
namespaceSelectorSelects the namespace(s) to which this policy applies. Select a specific namespace by name using the label.selectorall()
typesApplies the policy based on the direction of the traffic. To apply the policy to inbound traffic, set to Ingress. To apply the policy to outbound traffic, set to Egress. To apply the policy to both, set to Ingress, Egress.Ingress, EgressList of stringsDepends on presence of ingress/egress rules*
ingressOrdered list of ingress rules applied by policy.List of Rule
egressOrdered list of egress rules applied by this policy.List of Rule
doNotTrack**Indicates to apply the rules in this policy before any data plane connection tracking, and that packets allowed by these rules should not be tracked.true, falsebooleanfalse
preDNAT**Indicates to apply the rules in this policy before any DNAT.true, falsebooleanfalse
applyOnForward**Indicates to apply the rules in this policy on forwarded traffic as well as to locally terminated traffic.true, falsebooleanfalse

* If types has no value, Calico Cloud defaults as follows.

Ingress Rules PresentEgress Rules PresentTypes value
YesYesIngress, Egress

** The doNotTrack and preDNAT and applyOnForward fields are meaningful only when applying policy to a host endpoint.

Only one of doNotTrack and preDNAT may be set to true (in a given policy). If they are both false, or when applying the policy to a workload endpoint, the policy is enforced after connection tracking and any DNAT.

applyOnForward must be set to true if either doNotTrack or preDNAT is true because for a given policy, any untracked rules or rules before DNAT will in practice apply to forwarded traffic.


A single rule matches a set of packets and applies some action to them. When multiple rules are specified, they are executed in order.

FieldDescriptionAccepted ValuesSchemaDefault
metadataPer-rule metadata.RuleMetadata
actionAction to perform when matching this rule.Allow, Deny, Log, Passstring
protocolPositive protocol match.TCP, UDP, ICMP, ICMPv6, SCTP, UDPLite, 1-255string | integer
notProtocolNegative protocol match.TCP, UDP, ICMP, ICMPv6, SCTP, UDPLite, 1-255string | integer
icmpICMP match criteria.ICMP
notICMPNegative match on ICMP.ICMP
ipVersionPositive IP version match.4, 6integer
sourceSource match parameters.EntityRule
destinationDestination match parameters.EntityRule
httpMatch HTTP request parameters. Application layer policy must be enabled to use this field.HTTPMatch

After a Log action, processing continues with the next rule; Allow and Deny are immediate and final and no further rules are processed.

An action of Pass in a NetworkPolicy or GlobalNetworkPolicy will skip over the remaining policies and jump to the first profile assigned to the endpoint, applying the policy configured in the profile; if there are no Profiles configured for the endpoint the default applied action is Deny.


Metadata associated with a specific rule (rather than the policy as a whole). The contents of the metadata does not affect how a rule is interpreted or enforced; it is simply a way to store additional information for use by operators or applications that interact with Calico Cloud.

annotationsArbitrary non-identifying of string to string


app: database
owner: devops

Annotations follow the same rules as Kubernetes for valid syntax and character set.

On Linux with the iptables dataplane, rule annotations are rendered as comments in the form -m comment --comment "<key>=<value>" on the iptables rule(s) that correspond to the Calico Cloud rule.


FieldDescriptionAccepted ValuesSchemaDefault
typeMatch on ICMP type.Can be integer 0-254integer
codeMatch on ICMP code.Can be integer 0-255integer


Entity rules specify the attributes of the source or destination of a packet that must match for the rule as a whole to match. Packets are matched on their IPs and ports. If the rule contains multiple match criteria (for example, an IP and a port) then all match criteria must match for the rule as a whole to match.

Selectors offer a powerful way to select the source or destination to match based on labels.
Selectors can match workload endpoints, host endpoint and (namespaced or global) network sets.

FieldDescriptionAccepted ValuesSchemaDefault
netsMatch packets with IP in any of the listed CIDRs.List of valid IPv4 CIDRs or list of valid IPv6 CIDRs (IPv4 and IPv6 CIDRs shouldn't be mixed in one rule)list of cidrs
notNetsNegative match on CIDRs. Match packets with IP not in any of the listed CIDRs.List of valid IPv4 CIDRs or list of valid IPv6 CIDRs (IPv4 and IPv6 CIDRs shouldn't be mixed in one rule)list of cidrs
selectorPositive match on selected endpoints. If a namespaceSelector is also defined, the set of endpoints this applies to is limited to the endpoints in the selected namespaces.Valid selectorselector
notSelectorNegative match on selected endpoints. If a namespaceSelector is also defined, the set of endpoints this applies to is limited to the endpoints in the selected namespaces.Valid selectorselector
namespaceSelectorPositive match on selected namespaces. If specified, only workload endpoints in the selected Kubernetes namespaces are matched. Matches namespaces based on the labels that have been applied to the namespaces. Defines the scope that selectors will apply to, if not defined then selectors apply to the NetworkPolicy's namespace. Match a specific namespace by name using the label. Select the non-namespaced resources like GlobalNetworkSet(s), host endpoints to which this policy applies by using global() selector.Valid selectorselector
portsPositive match on the specified portslist of ports
domainsPositive match on domain names.List of exact or wildcard domain nameslist of strings
notPortsNegative match on the specified portslist of ports
serviceAccountsMatch endpoints running under service accounts. If a namespaceSelector is also defined, the set of service accounts this applies to is limited to the service accounts in the selected namespaces.ServiceAccountMatch
servicesMatch the specified service(s). If specified on egress rule destinations, no other selection criteria can be set. If specified on ingress rule sources, only positive or negative matches on ports can be specified.ServiceMatch

You cannot mix IPv4 and IPv6 CIDRs in a single rule using nets or notNets. If you need to match both, create 2 rules.

Exact and wildcard domain names

The domains field is only valid for egress Allow rules. It restricts the rule to apply only to traffic to one of the specified domains. If this field is specified, the parent Rule's action must be Allow, and nets and selector must both be left empty.

When a configured domain name has no wildcard (*), it matches exactly that domain name. For example:


With a single asterisk in any part of the domain name, it matches 1 or more path components at that position. For example:

  • * matches and, but not
  • www.*.com matches and, but not
  •* matches,, and so on
  • update.* matches,, and so on

Not supported are:

  • Multiple wildcards in the same domain, for example: *.*
  • Asterisks that are not the entire component, for example: www.g*.com
  • More general wildcards, such as regular expressions

Calico Cloud implements policy for domain names by learning the corresponding IPs from DNS, then programming rules to allow those IPs. This means that if multiple domain names A, B and C all map to the same IP, and there is domain-based policy to allow A, traffic to B and C will be allowed as well.


A label selector is an expression which either matches or does not match a resource based on its labels.

Calico Cloud label selectors support a number of operators, which can be combined into larger expressions using the boolean operators and parentheses.

Logical operators
( <expression> )Matches if and only if <expression> matches. (Parentheses are used for grouping expressions.)
! <expression>Matches if and only if <expression> does not match. Tip: ! is a special character at the start of a YAML string, if you need to use ! at the start of a YAML string, enclose the string in quotes.
<expression 1> && <expression 2>"And": matches if and only if both <expression 1>, and, <expression 2> matches
<expression 1> || <expression 2>"Or": matches if and only if either <expression 1>, or, <expression 2> matches.
Match operators
all()Match all in-scope resources. To match no resources, combine this operator with ! to form !all().
global()Match all non-namespaced resources. Useful in a namespaceSelector to select global resources such as global network sets.
k == 'v'Matches resources with the label 'k' and value 'v'.
k != 'v'Matches resources without label 'k' or with label 'k' and value not equal to v
has(k)Matches resources with label 'k', independent of value. To match pods that do not have label k, combine this operator with ! to form !has(k)
k in { 'v1', 'v2' }Matches resources with label 'k' and value in the given set
k not in { 'v1', 'v2' }Matches resources without label 'k' or with label 'k' and value not in the given set
k contains 's'Matches resources with label 'k' and value containing the substring 's'
k starts with 's'Matches resources with label 'k' and value starting with the substring 's'
k ends with 's'Matches resources with label 'k' and value ending with the substring 's'

Operators have the following precedence:

  • Highest: all the match operators
  • Parentheses ( ... )
  • Negation with !
  • Conjunction with &&
  • Lowest: Disjunction with ||

For example, the expression

! has(my-label) || my-label starts with 'prod' && role in {'frontend','business'}

Would be "bracketed" like this:

((!(has(my-label)) || ((my-label starts with 'prod') && (role in {'frontend','business'}))

It would match:

  • Any resource that did not have label "my-label".
  • Any resource that both:
    • Has a value for my-label that starts with "prod", and,
    • Has a role label with value either "frontend", or "business".

Understanding scopes and the all() and global() operators: selectors have a scope of resources that they are matched against, which depends on the context in which they are used. For example:

  • The nodeSelector in an IPPool selects over Node resources.

  • The top-level selector in a NetworkPolicy selects over the workloads in the same namespace as the NetworkPolicy.

  • The top-level selector in a GlobalNetworkPolicy doesn't have the same restriction, it selects over all endpoints including namespaced WorkloadEndpoints and non-namespaced HostEndpoints.

  • The namespaceSelector in a NetworkPolicy (or GlobalNetworkPolicy) rule selects over the labels on namespaces rather than workloads.

  • The namespaceSelector determines the scope of the accompanying selector in the entity rule. If no namespaceSelector is present then the rule's selector matches the default scope for that type of policy. (This is the same namespace for NetworkPolicy and all endpoints/network sets for GlobalNetworkPolicy)

  • The global() operator can be used (only) in a namespaceSelector to change the scope of the main selector to include non-namespaced resources such as GlobalNetworkSet. This allows namespaced NetworkPolicy resources to refer to global non-namespaced resources, which would otherwise be impossible.


Calico Cloud supports the following syntaxes for expressing ports.

int80The exact (numeric) port specified
start:end6040:6050All (numeric) ports within the range start <= x <= end
stringnamed-portA named port, as defined in the ports list of one or more endpoints

An individual numeric port may be specified as a YAML/JSON integer. A port range or named port must be represented as a string. For example, this would be a valid list of ports:

ports: [8080, '1234:5678', 'named-port']

Named ports

Using a named port in an EntityRule, instead of a numeric port, gives a layer of indirection, allowing for the named port to map to different numeric values for each endpoint.

For example, suppose you have multiple HTTP servers running as workloads; some exposing their HTTP port on port 80 and others on port 8080. In each workload, you could create a named port called http-port that maps to the correct local port. Then, in a rule, you could refer to the name http-port instead of writing a different rule for each type of server.


Since each named port may refer to many endpoints (and Calico Cloud has to expand a named port into a set of endpoint/port combinations), using a named port is considerably more expensive in terms of CPU than using a simple numeric port. We recommend that they are used sparingly, only where the extra indirection is required.


A ServiceAccountMatch matches service accounts in an EntityRule.

namesMatch service accounts by namelist of strings
selectorMatch service accounts by labelselector


A ServiceMatch matches a service in an EntityRule.

nameThe service's name.string
namespaceThe service's namespace.string

Supported operations

Datastore typeCreate/DeleteUpdateGet/ListNotes
Kubernetes API datastoreYesYesYes