Skip to content

Interpret Cilium Network Policies and Intent: CCA practice questions

Reading a Cilium policy correctly starts with one question: which endpoints does it select? The endpointSelector picks the pods the rule protects, always within the namespace of a CiliumNetworkPolicy, and everything below it describes what those pods may receive (ingress) or send (egress).

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Interpret Cilium Network Policies and Intent covers in CCA

Reading a Cilium policy correctly starts with one question: which endpoints does it select? The endpointSelector picks the pods the rule protects, always within the namespace of a CiliumNetworkPolicy, and everything below it describes what those pods may receive (ingress) or send (egress). Peers are chosen with fromEndpoints or toEndpoints for Cilium-managed pods, fromEntities or toEntities for well-known groups such as world, host or kube-apiserver, CIDR rules for addresses outside Cilium's control, and toFQDNs for external names.

The model is a whitelist. Each rule allows the traffic it matches, overlapping rules allow their union, and anything left over is dropped once the endpoint is in default deny for that direction. Enforcement is stateful, so a rule that lets A open connections to B also lets B's replies through, but it never lets B start a session toward A. When you see an ingress rule on a backend, ask whether the frontend also needs an egress allow; that depends on whether some policy selects the frontend for egress.

Ports narrow the meaning further. A toPorts block next to a peer means the peer may connect only on those ports, and an empty or missing peer with toPorts means any peer on those ports. Adding an L7 section under toPorts changes how violations look: HTTP requests that do not match the listed method, path, host or headers get a 403 from the node-local Envoy proxy, and blocked DNS queries get REFUSED, instead of a silent drop.

Deny sections reverse the usual reading. ingressDeny and egressDeny subtract traffic, and they win over any allow, including allows from other policies and from Kubernetes NetworkPolicy. A cluster-wide policy that allows all and denies world therefore expresses the intent "everything except the outside world". Deny rules cannot match URLs or DNS names.

DNS-based egress usually appears as a pair. One rule lets pods talk to kube-dns on port 53 and sends the queries through the DNS proxy with a dns matchName or matchPattern; a second rule lists toFQDNs names whose resolved IPs become allowed destinations. The two lists are independent: a pod may be allowed to resolve a name it is still not allowed to connect to. Namespace labels in a peer selector, such as k8s:io.kubernetes.pod.namespace or io.cilium.k8s.namespace.labels.<key>, let a policy reach pods in other namespaces, while the selected pods themselves never leave the policy's namespace.

Key points

  • An endpointSelector in a CiliumNetworkPolicy can only pick pods of the namespace the policy lives in.
  • Replies to an allowed connection pass automatically; the opposite direction needs its own allow.
  • L7 violations produce HTTP 403 or DNS REFUSED responses rather than packet drops.
  • ingressDeny and egressDeny override any allow rule, whatever policy type the allow comes from.

Three sample questions

11 CCA questions on Interpret Cilium Network Policies and Intent, 11 with explanations. How practice works

Question 1

Which of the following is a valid Layer 7 protocol rule that can be enforced by Cilium?
  1. A.Restricting access based on HTTP methods and paths
  2. B.Filtering traffic based on the pod's startup time
  3. C.Allowing traffic only when the node CPU usage is below a threshold
  4. D.Limiting bandwidth for specific pods

Correct answer: A

Cilium can enforce Layer 7 protocol rules such as restricting access based on HTTP methods and paths, allowing fine-grained API-level access control.

Question 2

Which of the following would allow traffic only from pods labeled as "app=frontend" to access the "/api/v1/public" HTTP path?
  1. A.
    ingress:
- fromEndpoints:
  - matchLabels:
      app: frontend
  toPorts:
  - ports:
    - port: "80"
      protocol: TCP
    rules:
      http:
      - method: "GET"
        path: "/api/v1/public"
  2. B.
    ingress:
- fromEndpoints:
  - matchLabels:
      app: frontend
  http:
  - method: "GET"
    path: "/api/v1/public"
  3. C.
    ingress:
- fromCIDR:
  - 10.0.0.0/16
  toPorts:
  - ports:
    - port: "80"
      protocol: TCP
    http:
    - method: "GET"
      path: "/api/v1/public"
  4. D.
    ingress:
- fromEndpoints:
  - matchLabels:
      app: frontend
  toPorts:
  - ports:
    - port: "80"
      protocol: TCP
  http:
  - method: "GET"
    path: "/api/v1/public"

Correct answer: A

This is the correct structure for a Cilium L7 policy that allows traffic only from pods labeled as "app=frontend" to access the "/api/v1/public" HTTP path. The http rules must be nested under toPorts and within a rules section.

Question 3

Which Cilium Network Policy feature allows restricting access to external API endpoints based on specific HTTP paths?
  1. A.Layer 7 HTTP rules in a toPorts section of the policy
  2. B.Identity-based security
  3. C.DNS-based filtering with HTTP path awareness
  4. D.External entity matching

Correct answer: A

Paths are matched by Layer 7 rules: an http list with method and path regexes under toPorts.rules, enforced by the node-local Envoy proxy; requests that do not match get an HTTP 403. Why the other options are wrong. "Identity-based security": identities decide which peers may talk (L3), not which URL paths. "DNS-based filtering with HTTP path awareness": toFQDNs/DNS rules match names, they do not look at HTTP paths. "External entity matching": entities such as world select groups of peers, not request paths.

Sources: Cilium docs: Layer 7 Policies, Cilium docs: Layer 3 Policies

Practice this topic

Focus mode keeps every question on Interpret Cilium Network Policies and Intent until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

If a backend allows ingress from the frontend, does the frontend need an egress rule?

Only if some policy puts the frontend into egress default deny. Policy must permit the traffic on both sides when both sides are selected; an unselected sender has unrestricted egress.