Display host firewall status in cilium status

[pchaigno]

With this pull request, the cilium status command will display e.g.:

KVStore:                Ok   Disabled
Kubernetes:             Ok   1.21 (v1.21.0) [linux/amd64]
Kubernetes APIs:        ["cilium/v2::CiliumClusterwideNetworkPolicy", "cilium/v2::CiliumEndpoint", "cilium/v2::CiliumNetworkPolicy", "cilium/v2::CiliumNode", "core/v1::Namespace", "core/v1::Node", "core/v1::Pods", "core/v1::Service", "discovery/v1::EndpointSlice", "networking.k8s.io/v1::NetworkPolicy"]
KubeProxyReplacement:   Disabled
Host firewall:          Enabled    [enp0s3, enp0s8]
Cilium:                 Ok   1.10.90 (v1.10.90-3e9722fd5c)
NodeMonitor:            Listening for events on 2 CPUs with 64x4096 of shared memory
Cilium health daemon:   Ok
IPAM:                   IPv4: 3/254 allocated from 10.11.0.0/24, IPv6: 3/65534 allocated from fd00::/112
BandwidthManager:       EDT with BPF   [enp0s3, enp0s8]
Host Routing:           Legacy
Masquerading:           IPTables [IPv4: Enabled, IPv6: Enabled]
Controller Status:      23/23 healthy
Proxy Status:           OK, ip 10.11.0.62, 0 redirects active on ports 10000-20000
Hubble:                 Ok   Current/Max Flows: 4095/4095 (100.00%), Flows/s: 21.86   Metrics: Disabled
Encryption:             Disabled
Cluster health:         1/1 reachable   (2021-08-16T09:11:14Z)

Fixes: #14749.

[borkmann]

Host firewall: Enabled [enp0s3 10.0.2.15 fd00::b, enp0s8 192.168.33.11 fd01::b]

What is the context of the IP addresses related to HF? Shouldn't it be independent which L3 address is configured there, meaning, only configured devices (enp0s3, enp0s8) should be of interest? (Or are these NodePort related addresses?)

[pchaigno]

Host firewall: Enabled [enp0s3 10.0.2.15 fd00::b, enp0s8 192.168.33.11 fd01::b]

What is the context of the IP addresses related to HF? Shouldn't it be independent which L3 address is configured there, meaning, only configured devices (enp0s3, enp0s8) should be of interest? (Or are these NodePort related addresses?)

More or less. We do still rely on the IP addresses to know if the traffic entering the node is directed to the host namespace (based on HOST_ID).

[brb]

More or less. We do still rely on the IP addresses to know if the traffic entering the node is directed to the host namespace (based on HOST_ID).

@pchaigno Don't we use IPCache for that? If yes, then I assume that if any of those devices have multiple IP addrs (e.g., k8s ExternalIP and InternalIP), then all of them should be in the IPCache regardless of those shown in the status.

[brb]

LGTM, just one question regarding the IP addrs in the HF status.

[pchaigno]

More or less. We do still rely on the IP addresses to know if the traffic entering the node is directed to the host namespace (based on HOST_ID).

@pchaigno Don't we use IPCache for that? If yes, then I assume that if any of those devices have multiple IP addrs (e.g., k8s ExternalIP and InternalIP), then all of them should be in the IPCache regardless of those shown in the status.

Hm, you're right. The list of IP addresses is going to be misleading in that context. I'll remove it.

[pchaigno]

test-me-please

[brb]

@pchaigno GH shows me only one commit in this PR. Is it intended?

[pchaigno]

@pchaigno GH shows me only one commit in this PR. Is it intended?

Yes, the other two preparatory commits were only needed when displaying the IP addresses. I've updated the pull request description accordingly.

[brb]

🚀 (it would be nice if you could open a PR for that KPR little refactoring)