hubble: parser: Set Encrypted bit correctly #14677
Conversation
tgraf
added
kind/bug
The Encrypted flag has not been decoded correctly and inherited to the Hubble flow. Do so and add unit test. Signed-off-by: Thomas Graf <thomas@cilium.io>
tgraf
force-pushed
the
pr/tgraf/hubble-encrypt-bit
branch
from
4eaa562
to
7cea301
Compare
|
test-me-please |
| if ip != nil { | ||
| ip.Source = srcIP.String() | ||
| ip.Encrypted = (tn.Reason & monitor.TraceReasonEncryptMask) != 0 |
There was a problem hiding this comment.
Something to keep in mind here is that not all trace points set tn.Reason. So we need to be careful not confuse users with false negatives (we had a similar issue with the "is_reply" field).
A quick grep in the bpf sources seems to indicate that only the from-network and from-overlay trace points set TRACE_REASON_ENCRYPTED. I have not tested it, but does this mean that to-network will always report Encrypted as false?
Is this a problem? If so, we should either try to address that in the datapath or have a "Encrypted: unknown" state in Hubble.
There was a problem hiding this comment.
Good point. It's something we need to fix one layer below though. We need to be consistent. It must be possible to trust the flag.
|
retest-4.9 |
|
retest-runtime |
|
retest-net-next |
|
retest-4.9 |
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.8
in 1.8.7
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.8
in 1.8.7
maintainer-s-little-helper
bot
moved this from Backport pending to v1.8
to Backport done to v1.8
in 1.8.7
The Encrypted flag has not been decoded correctly and inherited to the
Hubble flow. Do so and add unit test.