Skip to content

Policy Rule Structure: CCA practice questions

Every Cilium policy, namespaced or cluster-wide, is built from the same Rule type. A CiliumNetworkPolicy carries one rule in spec or a list of rules in specs, the latter being handy when several rules should be added or removed as a unit.

By Ibrahim Yesilay · Published · Updated

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

What Policy Rule Structure covers in CCA

Every Cilium policy, namespaced or cluster-wide, is built from the same Rule type. A CiliumNetworkPolicy carries one rule in spec or a list of rules in specs, the latter being handy when several rules should be added or removed as a unit. Each rule has a selector, an ingress list, an egress list, optional deny lists, labels and a free-text description.

The selector is either an endpointSelector, based on the Kubernetes LabelSelector and matched against endpoint labels, or a nodeSelector, matched against node labels. The two are mutually exclusive, one of them must be set, and nodeSelector is only valid in a CiliumClusterwideNetworkPolicy, where it creates a host policy. A rule that has neither an ingress nor an egress section does nothing.

Ingress rules name allowed sources and egress rules name allowed destinations. The L3 part can be fromEndpoints/toEndpoints, entities, fromNodes/toNodes when node selector labels are enabled, CIDR lists and CIDR sets with exceptions, toServices for Kubernetes Services, or toFQDNs for DNS names. toFQDNs is restrictive: an egress rule that uses it cannot also contain toEndpoints, toCIDR or another L3 selector, though it may carry toPorts. The older fromRequires and toRequires fields were removed in Cilium 1.19.

The L4 part lives in toPorts. Each entry lists ports with a number or a named port, an optional endPort for ranges, and a protocol of TCP, UDP or ANY. ICMP is not matched there but in a separate icmps field, whose entries give a type as a number or CamelCase name and a family of IPv4 or IPv6. For TLS, serverNames under toPorts limits the SNI a pod may use, which requires the L7 proxy.

The L7 part is a rules block inside a toPorts entry. It is a union: http or dns, never both for one port. When several rules with the same port select overlapping endpoints, L7 rules of the same type are merged and different types cause the policy to be rejected. HTTP rules match method, path and host as extended POSIX regular expressions, plus required headers. DNS rules use matchName or matchPattern, where an asterisk matches any characters except the dot, so it stays within one label, and a leading **. matches subdomains at any depth.

Labels identify rules. Policies imported from Kubernetes automatically get io.cilium.k8s.policy.name set to the resource name, which tooling uses to find or delete them.

Key points

  • endpointSelector and nodeSelector are mutually exclusive; nodeSelector needs a cluster-wide policy.
  • Port ranges use port plus endPort; ICMP types go in icmps, not toPorts.
  • One port carries either http or dns L7 rules; mixing types for overlapping endpoints rejects the policy.
  • A toFQDNs egress rule may hold toPorts but no other L3 selector.

Three sample questions

10 CCA questions on Policy Rule Structure, 10 with explanations. How practice works

Question 1

Which component of the following CiliumNetworkPolicy defines which pods the policy applies to? 
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "secure-api"
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
  1. A.metadata
  2. B.ingress
  3. C.endpointSelector
  4. D.fromEndpoints

Correct answer: C

The endpointSelector field defines which pods the policy applies to by selecting pods based on labels. In this example, the policy applies to pods with the label "app: api".

Question 2

Which Cilium policy feature allows restricting egress traffic to specific domain names rather than IP addresses?
  1. A.toCIDR
  2. B.toFQDNs
  3. C.toEndpoints
  4. D.toDNS

Correct answer: B

The toFQDNs feature in Cilium policies allows restricting egress traffic to specific domain names rather than IP addresses, which is particularly useful for accessing external services with dynamic IPs.

Question 3

A CiliumNetworkPolicy has an endpointSelector but neither an ingress nor an egress section. What is its effect on the selected pods?
  1. A.All ingress and egress of the selected pods is denied
  2. B.None; the rule has no effect
  3. C.All ingress is denied and egress stays allowed
  4. D.The API server rejects the policy as invalid

Correct answer: B

Each rule has an ingress and an egress section. The Rule Basics docs state that either one or both can be given, and that if both are omitted the rule has no effect. Default deny is triggered by a selecting rule that has an ingress or egress section. Why the other options are wrong. "All ingress and egress of the selected pods is denied": Default deny needs a section for that direction. Without any section nothing changes. "All ingress is denied and egress stays allowed": An ingress section is needed to switch ingress into default deny. "The API server rejects the policy as invalid": The documented outcome is a rule with no effect, not a rejection.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Cilium docs: Policy Enforcement Modes, Cilium docs: Policy Enforcement

Practice this topic

Focus mode keeps every question on Policy Rule Structure 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.