Skip to content

Enabling Layer 7 Protocol Visibility: CCA practice questions

Out of the box, Cilium monitoring and Hubble report L3 and L4 events: addresses, identities, ports, TCP flags and verdicts. To see HTTP requests or DNS queries, the traffic has to pass through the node-local Envoy proxy, which parses the protocol and hands the result back to Hubble.

By Ibrahim Yesilay · Published · Updated

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

What Enabling Layer 7 Protocol Visibility covers in CCA

Out of the box, Cilium monitoring and Hubble report L3 and L4 events: addresses, identities, ports, TCP flags and verdicts. To see HTTP requests or DNS queries, the traffic has to pass through the node-local Envoy proxy, which parses the protocol and hands the result back to Hubble. In current Cilium releases the documented way to get that redirect is an ordinary CiliumNetworkPolicy with Layer 7 rules, and the feature needs L7 proxy support enabled in the agent.

The visibility guide uses one policy as its example. It selects every pod in the default namespace and defines two egress rules. The first allows traffic to kube-dns on port 53 with protocol ANY and a DNS rule with matchPattern "*". The second allows traffic to pods in the default namespace on TCP ports 80 and 8080 with http: [{}]. An empty HTTP rule and a wildcard DNS pattern place no conditions on the request, so everything that matches the L4 part is permitted, but it is now proxied and therefore visible. hubble observe -f -t l7 then prints dns-request, dns-response, http-request and http-response events with query names, answers, methods, URLs, status codes and latency.

There is a catch that the guide states plainly: an L7 policy is still a policy. Once it selects the pods for egress, egress traffic that matches neither rule is dropped. Adding visibility to a namespace therefore means writing rules that cover all the traffic you still want to allow. Violations of real L7 conditions are not silent drops either; Envoy answers with an HTTP 403 or a DNS REFUSED response.

L7 data can be sensitive. By default Hubble does not redact anything in L7 flows, so query strings, basic-auth credentials and headers may appear. The agent option --hubble-redact-enabled turns on redaction, with --hubble-redact-http-urlquery for query parameters, --hubble-redact-http-userinfo for user info in URLs, and allow or deny lists for HTTP headers.

Two limitations are listed. DNS visibility is available on egress only, and L7 policies for SNATed IPv6 traffic need a kernel that contains a specific fix. Visibility also drives metrics: Hubble HTTP metrics such as httpV2 are only emitted for pods whose traffic is visible at Layer 7.

Key points

  • L7 visibility comes from L7 rules in a CiliumNetworkPolicy and requires L7 proxy support.
  • http: [{}] or a DNS matchPattern of "*" permits every request on the port while making it visible.
  • Selected pods lose any traffic the visibility policy does not allow.
  • Redaction is off by default; enable it with --hubble-redact-enabled and its per-field options.
  • DNS visibility works on egress only.

Three sample questions

11 CCA questions on Enabling Layer 7 Protocol Visibility, 11 with explanations. How practice works

Question 1

Without any Layer 7 policy in place, what level of detail do Cilium datapath monitoring and Hubble show for a pod's traffic?
  1. A.Full HTTP request and response details for every port
  2. B.Only L3/L4 packet events
  3. C.DNS queries only, while all other traffic is hidden
  4. D.No events at all until Hubble Relay is installed

Correct answer: B

The Layer 7 Protocol Visibility page states that by default monitoring only provides visibility into L3/L4 packet events, and that L7 visibility needs L7 Cilium Network Policies. Why the other options are wrong. "Full HTTP request and response details for every port": HTTP details appear only for traffic redirected to the proxy by an L7 rule. "DNS queries only, while all other traffic is hidden": DNS details also need an L7 DNS rule, and L3/L4 events are shown for all traffic. "No events at all until Hubble Relay is installed": the per-node Hubble server already serves L3/L4 events; Relay only adds the cluster-wide view.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Cilium docs: Layer 7 Protocol Visibility, Cilium docs: Network Observability with Hubble

Question 2

In Cilium 1.20, how do you make HTTP requests to pods on TCP port 8080 visible in Hubble?
  1. A.Set hubble.relay.enabled=true and hubble.ui.enabled=true in the Helm values
  2. B.Run hubble observe --protocol http
  3. C.A CiliumNetworkPolicy with an L7 http rule (http: [{}]) on port 8080
  4. D.Enable kubeProxyReplacement=true on the agents

Correct answer: C

The visibility guide says to create a CiliumNetworkPolicy that specifies L7 rules; traffic matching an L7 rule is redirected to the proxy and becomes visible. An empty http rule permits all requests that match the L4 part of the rule. Why the other options are wrong. "Set hubble.relay.enabled=true and hubble.ui.enabled=true in ...": Relay aggregates the flows that exist; it does not make Cilium parse HTTP. "Run hubble observe --protocol http": this filters flows that are already being parsed; it does not enable parsing. "Enable kubeProxyReplacement=true on the agents": kube-proxy replacement is about service load balancing, not L7 visibility.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Cilium docs: Layer 7 Protocol Visibility, Cilium docs: Layer 7 Policies

Question 3

A team applies the documented l7-visibility policy (egress DNS rule to kube-dns and http: [{}] on ports 80 and 8080) to every pod in the default namespace. What side effect must they expect?
  1. A.None, because visibility policies only observe and never enforce
  2. B.All HTTP requests on ports 80 and 8080 receive HTTP 403
  3. C.Hubble automatically redacts every HTTP header of those pods
  4. D.Unmatched egress traffic from those pods is dropped

Correct answer: D

The guide warns that L7 network policies not only enable visibility but also restrict what traffic is allowed; the example restricts egress communication and drops anything that is not matched. Why the other options are wrong. "None, because visibility policies only observe and never ...": in Cilium a visibility policy is an ordinary L7 policy and is enforced like any other. "All HTTP requests on ports 80 and 8080 receive HTTP 403": http: [{}] has no matching conditions, so every request on those ports is permitted. "Hubble automatically redacts every HTTP header of those pods": redaction is off by default and is enabled separately with --hubble-redact-enabled.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), Cilium docs: Layer 7 Protocol Visibility, Cilium docs: Layer 7 Policies

Practice this topic

Focus mode keeps every question on Enabling Layer 7 Protocol Visibility 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

Will a visibility policy return HTTP 403 for normal requests?

Not with an empty rule such as http: [{}], which permits every request on that port. 403 responses only appear for requests that break L7 conditions you actually set, such as a method or path regex.