Global network policy

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

GlobalNetworkPolicy resources can be used to define network connectivity rules between groups of Calico endpoints and host endpoints, and take precedence over if any are defined.

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

Spec

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

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

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.

See for how doNotTrack and preDNAT and applyOnForward can be useful for host endpoints.

Rule

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

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 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.

RuleMetadata

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.

Example:

metadata:
  annotations:
    app: database
    owner: devops

Annotations follow the .

EntityRule

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 , host endpoint and (namespaced or ) network sets.

When using selectors in network policy, remember that selectors only match (known) resources, but rules match packets. A rule with a selector all() won’t match “all packets”, it will match “packets from all in-scope endpoints and network sets”. To match all packets, do not include a selector in the rule at all.

note

notSelector is somewhat subtle because the not in notSelector negates the packet match rather than the selector:

• selector: !has(foo) matches packets from/to endpoints and network sets that do not have the label “foo”.
• notSelector: has(foo) matches packets from/to anywhere (including outside the cluster), except traffic from/to endpoints and network sets that have the label “foo”.

Selectors

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

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

Operators have the following precedence:

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

For example, the expression

Would be “bracketed” like this:

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

It would match:

• 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 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.

Ports

Calico supports the following syntaxes for expressing ports.

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

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.

note

Since each named port may refer to many endpoints (and Calico 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.

ServiceMatch

A ServiceMatch matches a service in an EntityRule.

Application layer policy is an optional feature of Calico and in order to use the following match criteria.

note

Application layer policy match criteria are supported with the following restrictions.

• Only ingress policy is supported. Egress policy must not contain any application layer policy match clauses.
• Rules must have the action Allow if they contain application layer policy match clauses.

HTTPMatch

Example:

http:
  methods: ['GET', 'PUT']
  paths:
    - prefix: '/users'

HTTPPathMatch