Add policy verdicts GSG

[joestringer]

This is based on some v1.8 blog material I was working on, but I figured it might be useful as a beginner introduction to forming policy from monitor output.

[coveralls]

Coverage decreased (-0.01%) to 37.092% when pulling 92e3b2c on joestringer:submit/policy-verdicts into 16907c4 on cilium:master.

[michi-covalent]

thanks for documenting this @joestringer this is super educational!

one thing that's not obvious to me is how one would pick ingress vs egress policy. the example seems slightly arbitrary in a sense that it just happened to get policy-verdict for ingress traffic and proceeds to define an ingress policy. providing a bit more background might help, something like:

1. i want to protect the deathstar pod by defining an ingress poilcy.
2. right now i don't know which endpoints access deathstar on which ports.
3. i can run cilium monitor -t policy-verdict on the node deathstar is running to discover who's accessing deathstar.
4. then define an ingress policy. it might be even better if there are multiple endpoints accessing deathstar so that we can show both action allow and action drop.

cc @rolinh this can be a good demo scenario for hubble-relay to gather policy verdict notifications from all the nodes without having to exec into a specific cilium pod :)

[michi-covalent]

not directly related to the documentation, but kind of curious why policy-verdict shows endpoint id for local and security identity for remote.

[joestringer]

Great question. @ap4y do you recall why this is?

[joestringer]

Actually this may just be historic in that all of the BPF notification types followed this approach.

[ap4y]

I'm not entirely sure, @lzang probably knows more about the design decision for this one. AFAIK security identity is used during the verdict resolution so it makes sense to expose it in the policy log. Source is set automatically based on the datapath via a common header of the message payload:

cilium/bpf/lib/common.h

Lines 270 to 274 in 0fa8ac7

	#define __notify_common_hdr(t, s) \
	.type = (t), \
	.subtype = (s), \
	.source = EVENT_SOURCE, \
	.hash = get_hash_recalc(ctx)

And we have source defined in the datapath implementation:

cilium/bpf/bpf_lxc.c

Line 12 in 0fa8ac7

#define EVENT_SOURCE LXC_ID

[joestringer]

Maybe makes sense for us to take another look at the CLI output and see whether there are some basic quality-of-life things like this to also print the source local identity.

[tklauser]

Once #12137 is merged, this example output should probably be updated to the new format.

[tklauser]

Same here, this needs to be updated once #12137 is merged.

[rolinh]

cc @rolinh this can be a good demo scenario for hubble-relay to gather policy verdict notifications from all the nodes without having to exec into a specific cilium pod :)

Indeed! Maybe something to add to the new getting started with hubble guide.

[joestringer]

@michi-covalent thanks for the detailed review! I revamped/expanded tthe guide and hopefully this addresses your questions&feedback.

[michi-covalent]

went through the guide, it worked seamlessly 💯

maybe we can reference https://www.starwars.com/video/one-in-a-million-shot at the end of the guide, but it does mean the force was too strong with this one even for cilium to protect death star.

[michi-covalent]

lgtm! went through the Disable Policy Audit Mode section. just a few minor nits