Parent: #2594

Cilium API policies implemented by BPF datapath in Cilium 1.0-rc6

Actual behaviour as at 2018-03-02

This issue attempts to capture the datapath-level perspective on how policy is enforced in Cilium as of https://github.com/cilium/cilium/tree/v1.0.0-rc6 , so that as we review the network policy model (#2594) we can plan for necessary datapath changes.

Interpretation Notes:

• Rule name column is provided for discussion reference.
• Each row represents a single rule.
• toServices is translated into toCIDR in the datapath, and in the table below.
• fromEndpoints / toEndpoints is represented as fromIdentity / toIdentity in the below table.
• fromEntities / toEntities is represented as fromIdentity / toIdentity in the below table.
• toPorts matches destination port range in UDP/TCP after service translation is applied.

Ingress

Egress

Annotations

1. ∃ a proposal to restrict union of identity / cidr at API layer (Policy Spec v3 #3005)
2. The documentation specifies that it's "OR", but when fields are specified together in other rules, they're typically "AND"- for example, allow traffic that matches particular L4 ports AND labels.
3. Requires L4 lookup as part of the CIDR map lookup
4. Ingress toPorts is unsupported, however similar behaviour may be supported via "Label-dependent L4" with a wildcard endpoint selector.
5. Egress toCIDR is only applied to traffic with destination IP that:
   • Does not match a local endpoint IP
   • Does not match a remote node destination prefix
   • Does not match the cluster prefix

Implications on datapath design

• Supporting fromEndpoints AND toPorts requires both of these to be part of
  the same lookup. This is the case for ingress and for planned egress
  label-based policy.
• Similarly, to implement toCIDR AND toPorts, the ports must become part of
  the lookup.
• If we reject containing fromEndpoints and fromCIDR from the same policy,
  then the datapath can retain separate maps for these, which for the
  identity(+L4)-based map may be a plain hash lookup, while for fromCIDR it
  may be an LPM
• If we add another policy stage before the service translation, then every
  constraint we intend to enforce at the same time must be part of that lookup.

Follow-up items

• Check that rules C, F-K, M are rejected at API layer (Reject policies that contain rules with more than one L3 match in a single rule #3015)
• Update documentation to refer to label-based l4 as such, not layer 3 dependent
  • Allows us to refer to label-dependent or CIDR-dependent and have that make sense
• Document where CIDR policies may be applied
  • fromCIDR only makes sense at ingress
  • toCIDR only makes sense at egress
• Document and/or validate API for fromEntities + toPorts

Discussion

• Policy constraints that apply at the same time as other policy constraints
  must be part of the same lookup. For example, to implement Labels+L4, both
  are part of the same BPF map.
• There's a proposal to introduce new services-specific policies, so the above
  table would add another column on egress for allowing destination services.
  Initial implementation would likely only support in combination with L4
  ports. This could be implemented by embedding such policy into the existing
  service translation lookup.