Skip to main content

Browse the archive

https://github.com/cilium/cilium
12 July 2024, 03:14:21 UTC
sort by:
Revision Author Date Message Commit Date
8b532b5 Andrew Sauber 11 April 2024, 18:16:29 UTC Prepare for release v1.13.15 Signed-off-by: Andrew Sauber <2046750+asauber@users.noreply.github.com> 11 April 2024, 21:50:04 UTC
33c7352 Jarno Rajahalme 03 April 2024, 11:47:07 UTC service: Update for L7 LB while locked [ upstream commit d913b6298123064f51a8b97495f956b5ebbe62b7 ] Keep service manager locked while reupserting services after L7 LB redirection updates. This removes the race where a service would be re-upserted while having been (concurrently) removed. Fixes: #18894 Reported-by: Jussi Maki <joamaki@isovalent.com> Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 11 April 2024, 09:08:10 UTC
9246f38 Robin Hahling 09 April 2024, 12:49:43 UTC enable renovate for cilium/certgen Signed-off-by: Robin Hahling <robin.hahling@gw-computing.net> 11 April 2024, 09:06:11 UTC
bd82720 Robin Hahling 09 April 2024, 12:29:45 UTC update cilium/certgen to v0.1.11 v0.1.10 and v0.1.11 are patch releases which update the Go version and dependencies. See releases for details: v0.1.10: https://github.com/cilium/certgen/releases/tag/v0.1.10 v0.1.11: https://github.com/cilium/certgen/releases/tag/v0.1.11 Signed-off-by: Robin Hahling <robin.hahling@gw-computing.net> 11 April 2024, 09:06:11 UTC
2de7399 Feroz Salam 10 April 2024, 09:53:20 UTC Bump google.golang.org/grpc to v1.63.2 (v1.13) Clears some recent CVEs. Signed-off-by: Feroz Salam <feroz.salam@isovalent.com> 10 April 2024, 15:08:08 UTC
f7ac35c Birol Bilgin 08 April 2024, 10:37:49 UTC ci: remove no longer supported k8s v1.24 K8S version 1.24 is no longer supported in GKE Regular channel This commit removes this version from tested k8s versions Signed-off-by: Birol Bilgin <birol@cilium.io> 10 April 2024, 13:22:18 UTC
a83e3d7 renovate[bot] 08 April 2024, 12:39:39 UTC chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> 10 April 2024, 12:56:14 UTC
e274a96 Nate Sweet 05 April 2024, 01:01:59 UTC fqdn: Fix Restore Check Logic [ upstream commit 79029db115743b9884a06e1acf0067140d8a33fe ] Sometimes restored IPRules do not have the default "nil" populating their IP maps, but instead have an empty map structure. We need to check for this restore possibility. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 10 April 2024, 09:05:26 UTC
95403dd Cilium Imagebot 04 April 2024, 06:51:52 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 09 April 2024, 09:12:51 UTC
3e9acf2 renovate[bot] 04 April 2024, 06:23:02 UTC chore(deps): update go to v1.21.9 Signed-off-by: renovate[bot] <bot@renovateapp.com> 09 April 2024, 09:12:51 UTC
dc486d2 David Bimmler 28 February 2024, 12:21:23 UTC controlplane: fix mechanism for ensuring watchers [ upstream commit fe71a4aef3bdd2fdafa7a8cbdf3dc71d29f18cf7 ] [ backporter: fix trivial conflics ] I realized that the fix for controlplane tests isn't complete. There is still a (small) race window: The current watch reaction records a watcher as established without "handling" the watch itself, i.e. it lets the default watch reaction actually call 'Watch' on the tracker. This is racy, as things can happen in the window between recordng and actually watching. To fix this, add the recording unconditionally in the existing tracker augmentation. Fixes: ba99d74c44 (controlplane: add mechanism to wait for watchers) Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 08 April 2024, 07:15:49 UTC
6388fe0 David Bimmler 22 February 2024, 15:15:14 UTC controlplane: wait for watcher establishment [ upstream commit 955049a8c6339ae8983fa8f041062e850ddcd5a3 ] [ backporter: fix trivial conflicts ] Use the infrastructure introduced in the previous commit to deflake control plane tests which update k8s state after starting the agent. Co-authored-by: Fabian Fischer <fabian.fischer@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 08 April 2024, 07:15:49 UTC
70e1d7c David Bimmler 22 February 2024, 14:56:56 UTC controlplane: add mechanism to wait for watchers [ upstream commit ba99d74c444ec3bdcd7d32bd4bbec1d76f85cdd2 ] [ backporter: lock.Map -> sync.Map ] We've recently learned that the fake k8s client set's object tracker do not respect the semantics of the real api-server when it comes to 'Watch': since the object tracker does not care for ResourceVersions, it cannot respect the version from which it ought to replay events. As a result, the default informer (more precisely, its reflector) is racy: it uses a ListAndWatch approach, which relies on this resource version to avoid a race window between the end of list and the beginning of watch. Therefore, all informers used in cilium have a low chance of hitting this race when used with a k8s fake object tracker. This is somewhat known in the k8s community, see for example [1]. However, the upstream response is that one simply shouldn't be using the fake infrastructure to test real informers. Unfortunately, this pattern is used somewhat pervasively inside the cilium tests, specifically so in the controlplane tests. This patch introduces a mechanism which reduces the likelihood of hitting the flake, under the assumption that we do not (often) establish multiple watchers for the same resource. In the following patch, we'll use the new infrastructure to reduce the flakiness of tests. [1]: https://github.com/kubernetes/kubernetes/issues/95372 Co-authored-by: Fabian Fischer <fabian.fischer@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 08 April 2024, 07:15:49 UTC
be25f29 David Bimmler 22 February 2024, 12:27:55 UTC controlplane: fix panic: send on closed channel [ upstream commit 7df437a0d03e91ea137836b5fa3436fe60e3cdc8 ] Rarely, the control plane test panics, due to a send on a closed channel. This can occur in a narrow race window in the filteringWatcher: 1. Stop is called on the child watcher 2. Child watcher calls stop on parent watcher 3. Concurrently, an event is dequeued from the parent result chan, and we enter the filtering logic. 4. The parent result chan is closed, and we close the child event channel 5. The filter is matched, and we attempt to write on the closed channel, which causes the panic. Instead of closing the channel in the Stop method, close the channel from the writing goroutine (as is commonly considered best practice in Go.) Fixes: fa89802ce7 (controlplane: Implement filtering of objects with field selectors) Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 08 April 2024, 07:15:49 UTC
37ef483 Tam Mach 06 April 2024, 07:28:29 UTC envoy: Bump envoy version to v1.27.4 This is mainly to resolve CVE-2024-30255. Related: https://github.com/envoyproxy/envoy/security/advisories/GHSA-j654-3ccm-vfmm Related build: https://github.com/cilium/proxy/actions/runs/8579381142/job/23514301386 Related release: https://github.com/envoyproxy/envoy/releases/tag/v1.27.4 Signed-off-by: Tam Mach <tam.mach@cilium.io> 06 April 2024, 11:14:51 UTC
22921f5 Marcel Zieba 13 March 2024, 14:33:57 UTC bpf, maps: Don't propagate nodeID to bpf map when allocation fails. [ upstream commit c1985037353fa8c7dd2f2eee7dda8cb0797b3b49 ] [ backporter's note: allocateIDForNode no longer returns error ] When we run out of IDs to allocate for nodes, we were propagating zero ID to bpf map. Now we just simply return error and not modify bpf map instead. Also clean up incorrectly mapped nodeids on startup in case that happened. Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> 05 April 2024, 12:43:17 UTC
8ae1672 Paul Chaignon 26 March 2024, 18:01:57 UTC workflows: Debug info for key rotations [ upstream commit 820aa07acdcdcb160b62574cdf2a766cf47f5da0 ] During the key rotations, we compare the number of keys to the expected number to know where we are in the process (started the rotation or finished it). The expected number of keys depends on the configuration so let's print it in the logs to help debug. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
a95e33d Quentin Monnet 28 March 2024, 10:00:45 UTC ci/ipsec: Print more info to debug credentials removal check failures [ upstream commit 129f2e235e62445b73a1b5630f1f7a3a36bf5014 ] In commit 6fee46f9e753 ("ci/ipsec: Fix downgrade version retrieval") we added a check to make sure that GitHub credentials are removed before pulling the untrusted branch from the Pull Request's author. It appears that this check occasionally fails and causes the whole job to abort. But Cilium's repository _is_ public, and it's unclear why ".private == false" does not evaluate to "false" as we expected in that case. Did the curl request fail? Did the reply miss the expected .private field? We'll probably loosen the check as a workaround, but before that it would be interesting to understand better what's going on. Here we remove the -s flag from curl and print the reply from the GitHub API request, so we can better understand what's going on next time we observe a failure. Signed-off-by: Quentin Monnet <qmo@qmon.net> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
dcf4f5e Tobias Klauser 27 March 2024, 14:01:44 UTC install/kubernetes: use renovate to update quay.io/cilium/startup-script [ upstream commit ac804b6980aac59950e23484809cbc2cafa318c2 ] Make sure the latest version of the image is used in the helm charts by letting renovatebot update it automatically. Signed-off-by: Tobias Klauser <tobias@cilium.io> 05 April 2024, 12:00:13 UTC
094fcac Tobias Klauser 27 March 2024, 13:38:55 UTC install/kubernetes: use digest for nodeinit image [ upstream commit 2d32dab5451d6ecc1dd1de3bc39f1070ff02b6b5 ] Like other images used in the Cilium helm chart, use a digest in addition to the tag for the nodeinit image. Signed-off-by: Tobias Klauser <tobias@cilium.io> 05 April 2024, 12:00:13 UTC
006a522 Sebastian Wicki 26 March 2024, 15:56:20 UTC cilium-health: Fix broken retry loop in `cilium-health-ep` controller [ upstream commit 43bd8c17f020eea053aab71216c37e2814fc4570 ] This commit fixes a bug in the `cilium-health-ep` controller restart logic where it did not give the cilium-health endpoint enough time to startup before it was re-created. For context, the `cilium-health-ep` performs two tasks: 1. Launch the cilium-health endpoint when the controller is started for the first time. 2. Ping the cilium-health endpoint, and if it does not reply, destroy and re-create it. The controller has a `RunInterval` of 60 seconds and a default `ErrorRetryBaseDuration` of 1 second. This means that after launching the initial cilium-health endpoint, we wait for 60 seconds before we attempt to ping it. If that ping succeeds, we then keep pinging the health endpoint every 60 seconds. However, if a ping fails, the controller deletes the existing endpoint and creates a new one. Because the controller then also returns an error, it is immediately re-run after one second, because in the failure case a controller retries with an interval of `consecutiveErrors * ErrorRetryBaseDuration`. This meant that after a failed ping, we deleted the unreachable endpoint, recreated a new one, and after 1s would immediately try to ping it. Because the newly launched endpoint will is unlikely to be reachable after just one second (it requires a full endpoint regeneration with BPF compilation), the `cilium-health-ep` logic would declare the still starting endpoint as dead and re-create it. This loop would continue endlessly, causing lots of unnecessary CPU churn, until enough consecutive errors have happened for the wait time between launch and the first ping to be long enough for a cilium-health endpoint to be fully regenerated. This commit attempts to fix the logic by not immediately killing a unreachable health endpoint and instead waiting for three minutes to pass before we attempt to try again. Three minutes should hopefully be enough time for the initial endpoint regeneration to succeed. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 05 April 2024, 12:00:13 UTC
14ca5ac Paul Chaignon 26 March 2024, 22:49:48 UTC docs: Document No node ID drops in case of remote node deletion [ upstream commit e2e97f3e07843f568813f90500ba75b21c462b8b ] While testing cluster scale downs, we noticed that under constant traffic load, we sometimes had drops of type "No node ID found". We confirmed that these are expected when the remote node was just deleted, the delete event received by the local agent, but a local pod is still sending traffic to pods on that node. In that case, the node is removed from the node ID map, but information on pods hosted by that node may still be present. This commit documents it with the other expected reasons for "No node ID found" drops. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
7d72965 Julian Wiedmann 14 March 2024, 10:11:09 UTC docs: ipsec: document native-routing + Egress proxy case [ upstream commit a2bf108c4d1652760953518397dedaf8755189f2 ] Let the docs reflect the limitation from https://github.com/cilium/cilium/security/advisories/GHSA-j89h-qrvr-xc36. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
2242cde David Bimmler 22 March 2024, 08:57:20 UTC endpointmanager: remove RemoveAll from interface [ upstream commit e2fbd38eebcf1dfb27baeb36bded4a1ba2f4efc3 ] Instead of having to import the testing pkg in non-testing code, let's remove the blocker on just having this method in the _test.go files. The endpoint manager in the daemon_test is re-initialized for every test, and since we don't have package global state any more we can just remove the call to RemoveAll, which solves all the problem nicely. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 05 April 2024, 12:00:13 UTC
fc48964 David Bimmler 19 March 2024, 10:07:59 UTC endpointmanager: check expose errors in test [ upstream commit fce11213dc1770272cbdd2b6c1adb49258ba0379 ] For some reason, lots of calls to expose didn't check the error returned. Specifically in the test context, this is not great, as it makes debugging test failures more difficult than necessary. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 05 April 2024, 12:00:13 UTC
349ba06 David Bimmler 19 March 2024, 09:17:27 UTC endpointmanager: deflake TestLookup [ upstream commit 0f27591862016285a9f2fc77298fa687b4b8477a ] TestLookup could fail with --- FAIL: Test (0.12s) --- FAIL: Test/EndpointManagerSuite (0.12s) --- FAIL: Test/EndpointManagerSuite/TestLookup (0.00s) manager_test.go:438: ... value *endpoint.Endpoint = &endpoint.Endpoint{[...]") ... Test Name: endpoint does not exist In about 0.02% of the runs. Specifically, it would fail iff the endpoint created happened to randomly get ID 1234, out of the pool of 4096 IDs. Fix this by not creating an endpoint unconditionally in the test, so that there is no chance of creating one with the "wrong" id. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 05 April 2024, 12:00:13 UTC
872a582 David Bimmler 19 March 2024, 08:56:07 UTC endpointmanager: move EP identifier alloc into pkg [ upstream commit a1a03cf55c98ca17ba99fba8f6c8e32c37c3c166 ] The endpoint manager assumed it was the only consumer of the idallocator pkg anyway. Having a pkg that only has one consumer is pointless, hence move it, including tests. This also allows unexporting everything, and reducing API surface. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 05 April 2024, 12:00:13 UTC
89cc23c David Bimmler 19 March 2024, 08:48:32 UTC endpointmanager: make idallocator a struct [ upstream commit 58ad35a84faab45fa0dab5f0078287f4cceb3926 ] The endpointmanagers idallocator package was using a package global pool for its identifier allocation. That's fine for running the agent, but causes flakes in testing when multiple tests access the same pool. It's also not idiomatic Go. This patch makes the local endpoint identifier allocator a struct, and the next patch will move it into the endpointmanager package itself, as there is no other consumer. While at it, also ensure that the RemoveAll method is only called from a testing context, by taking a testing.TB as an argument. We cannot simply move the method into the _test.go files, as tests from other packages use it. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
fdfbb25 David Bimmler 19 March 2024, 08:29:38 UTC endpointmanager: idallocator: remove checkmate [ upstream commit 59a31008b088400423aef9d5896952df781f81a2 ] Transform the test from using checkmate to standard Go tests, as it was not using any of the features anyway. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 05 April 2024, 12:00:13 UTC
f468c55 David Bimmler 19 March 2024, 08:17:55 UTC idpool: return pointer to pool [ upstream commit 0b56a2156595a2867bd8ebc2e35297c057e1b79f ] IDPool contains a mutex, passing copies around is a potential footgun. I don't think we ever used it incorrectly, but I don't see a reason for all the copying either. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
2cffd85 Ryan Drew 20 November 2023, 23:31:59 UTC docs: Restructure OpenShift installation instructions [ upstream commit efff613258445ca9986e1b6b74af07875f20099c ] This commit restructures the OpenShift installation instructions to point to the Red Hat Ecosystem Catalog, so users may find vendor maintained OLM images. The old installation instructions which refer to the deprecated cilium/cilium-olm repository will be moved to the isovalent/olm-for-cilium repository. Fixes: #24270 Signed-off-by: Ryan Drew <ryan.drew@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 05 April 2024, 12:00:13 UTC
0f41f5c Tam Mach 04 April 2024, 11:01:55 UTC envoy: Bump envoy image for golang 1.21.9 This is mainly for go 1.21.9 and ubuntu builder 22.04 image. Related build: https://github.com/cilium/proxy/actions/runs/8552986534/job/23435236145 Signed-off-by: Tam Mach <tam.mach@cilium.io> 05 April 2024, 06:21:12 UTC
d501652 Birol Bilgin 03 April 2024, 09:23:49 UTC fix aws regions when backporting ca-west-1 region used twice in tested aws k8s versions also ca-west-1 region is not supported by the eksctl tool used in testing this commit replaces ca-west-1 regions with ca-central-1 and us-east-1 Signed-off-by: Birol Bilgin <birol@cilium.io> 04 April 2024, 10:18:04 UTC
300b42c Nate Sweet 19 March 2024, 17:22:36 UTC testing: Update Restore Sort Method Signatrues [ upstream commit 51852524f8315d98fa82b292ac7254f0564bea3a ] The Sort methods are updated to take an unused testing.T structure to indicate to all callers that they are only for testing purposes. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 03 April 2024, 07:26:55 UTC
85432f0 Nate Sweet 13 March 2024, 20:24:50 UTC fqdn: Fallback to Version 1 Port Lookups [ upstream commit abd7c6e7fdca4352f2d83c0701d95d53cf3e10af ] In cases where a port-protocol is not present in an restored port protocol, look up up the Version 1 version of the PortoProto in case a Version 1 PortProto was restored. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 03 April 2024, 07:26:55 UTC
beba316 Nate Sweet 22 March 2024, 17:05:16 UTC endpoint: Create a New Restore Field for DNS [ upstream commit 6baab364c2fe71e54b50f3d746175ef1db75f6e2 ] DNSRulesV2 accounts for protocol and DNSRules does not. DNSProxy needs to account for both, and endpoint needs to be able to restore from a downgrade. DNSRulesV2 is used by default now, but DNSRules is maintained in case of a downgrade. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 03 April 2024, 07:26:55 UTC
4b3c1bd Nate Sweet 11 March 2024, 15:36:10 UTC fqdn: Add Protocol to DNS Proxy Cache [ upstream commit bc7fbf384bd2179c943130fc6842e27045c372de ] DNS Proxy indexes domain selectors by port only. In cases where protocols collide on port the DNS proxy may have a more restrictive selector than it should because it does not merge port protocols for L7 policies (only ports). All callers of the DNS Proxy are updated to add protocol to any DNS Proxy entries, and all tests are updated to test for port-protocol merge errors. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 03 April 2024, 07:26:55 UTC
b1d6e8b Nate Sweet 13 March 2024, 16:03:14 UTC fqdn: Update DNS Restore to Index to PortProto [ upstream commit 1941679572fd10932f20beb30a0dc6fd4c70c05f ] DNS Proxy needs to account for protocol when indexing L7 DNS rules that it needs to adhere to, otherwise L7 rules with differing port-protocols can override each other (nondeterministically) and create overly restrictive, and incorrect DNS rules. The problem with accounting for protocol is that Endpoint restoration logic uses DNS rules that index to port-only as JSON saved to disk. Adding an additional protocol index to a map structure changes the JSON structure and breaks restoration logic between Cilium versions. This change makes the map index backwards compatible, since it changes the index from a uint16 to a uint32, both of which marshal the same into a JSON structure. The endpoint restoration logic will succeed between versions, because the older version will be automatically differentiated with a lack of a 1-bit at bit position 24. Version 2 will save a 1 bit at the 24th bit going forward to differentiate when protocol is indexed or not present. Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 03 April 2024, 07:26:55 UTC
757634d Tam Mach 07 March 2024, 13:22:26 UTC envoy: Bump golang version to 1.21.8 This is to pick up the new image with updated golang version, and other dependency bump. Related commit: https://github.com/cilium/proxy/commit/99c1c8f42c8de70fc8f6dd594f4a425cd38b6688 Related build: https://github.com/cilium/proxy/actions/runs/8179378100/job/22365327840 Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
4f4e8e9 Tam Mach 05 March 2024, 08:34:35 UTC envoy: Drop privileges [upstream commit 3166f95] Use cilium-envoy image that drops privileges from the Envoy process before it starts. Envoy now needs to be started as `cilium-envoy-starter`, which drops all privileges before executing `cilium-envoy`. If `cilium-envoy` is executed directly with any privileges, it will terminate with the following error message when any Cilium filters are first configured: "[assert failure: get_capabilities(CAP_EFFECTIVE) == 0 && get_capabilities(CAP_PERMITTED) == 0. Details: cilium-envoy running with privileges, exiting" Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
63859d3 Tam Mach 05 March 2024, 07:21:53 UTC envoy: Update API to v1.27.0 [upstream commit 7404cb2] Update generated Envoy Go API for cilium-envoy based on Envoy 1.27.0. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
9be5bce Jarno Rajahalme 28 September 2023, 07:16:11 UTC envoy: Set enforce_policy_on_l7lb on l7 LB listener filters [ upstream commit 7646b69abf092991a1c3e0953e59725418b167ca ] Turn on ingress policy enforcement on L7 LB. With this cilium-envoy starts dropping Ingress traffic unless Cilium Agent configures it with a passing policy via the Ingress endpoint (with the reserved:ingress identity). Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 02 April 2024, 17:03:53 UTC
f71c6ec Jarno Rajahalme 04 October 2023, 12:07:54 UTC daemon: Add ingress endpoint [ upstream commit 04f19e98705ce54d6b6bb0c33a7d0af826c9900e ] Add Cilium Endpoint representing Ingress. It is defined without a veth interface and no bpf programs or maps are created for it. Ingress endpoint is needed so that the network policy is computed and configured to Envoy, so that ingress/egress network policy defined for Ingress can be enforced. Cilium Ingress is implemented as L7 LB, which is an Envoy redirect on the egress packet path. Egress CNP policies are already enforced when defined. Prior to this commit CNPs defined for reserved:ingress identity were not computed, however, and all traffic was passed through by Cilium Ingress was allowed to egress towards the backends. When the backends receive such packets, they are identified as coming from Cilium Ingress, so any ingress policies at the backends can not discern the original source of the traffic. This commit adds a Cilium endpoint for the reserved:ingress identity, which makes the Cilium node compute and pass policies whose endpoint selector selects this identity (e.g., by selecting all entities) to Envoy, so that they can be enforced. Envoy listener will then enforce not just the egress policy but also the ingress policy for the original incoming source security identity. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 02 April 2024, 17:03:53 UTC
fcaad4d Jarno Rajahalme 24 August 2023, 16:14:19 UTC envoy: Fix commants with references to deprecated uint64 policy ids [ upstream commit de085db6c50b613e37ed014328fcfae1003af244 ] Fix comments that still had references to the now-deprecated uint64 policy IDs. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 02 April 2024, 17:03:53 UTC
6e99f6e Jarno Rajahalme 13 October 2023, 07:22:46 UTC envoy: Bump envoy image to the latest v1.26.x [ upstream commit 34415bd203fb5cfe32fe829f04cd691ff6d35712 ] This commit is to perform the below: - Update envoy image to latest build from v1.26 branch - Include new resources into pkg/envoy/resource for serialization - grpc related resources are for upcoming support with GRPCRoute - Change policy id to uint32, related to https://github.com/cilium/proxy/commit/f37daf70991e4d58fc610244fb559cf48ea475e2 Related build: https://github.com/cilium/proxy/actions/runs/7070197416/job/19246669763 Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
7299a9e Tam Mach 18 June 2023, 12:13:32 UTC pkg: Remove pkg/policy/api/kafka module This module can be imported directly from cilium/proxy now Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
bc6f886 Tam Mach 18 June 2023, 11:35:08 UTC proxylib: Remove proxylib module This module is moved to cilium/proxy as part of the below PR, the main reason is to make sure that cilium/proxy container image is fully self-contained, and has no dependency with cilium/cilium. https://github.com/cilium/proxy/pull/232 Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
465f75d Tam Mach 12 June 2023, 06:00:05 UTC envoy: Use embedded proxylib from cilium-proxy container The same proxylib library is now available in cilium/proxy container. The image is built from https://github.com/cilium/proxy/actions/runs/5354917649/jobs/9712555724. Relates: https://github.com/cilium/proxy/pull/232 Signed-off-by: Tam Mach <tam.mach@cilium.io> 02 April 2024, 17:03:53 UTC
4c955ff renovate[bot] 01 April 2024, 14:28:36 UTC chore(deps): update stable lvh-images Signed-off-by: renovate[bot] <bot@renovateapp.com> 02 April 2024, 14:54:14 UTC
1d7c77d renovate[bot] 01 April 2024, 14:28:28 UTC chore(deps): update cilium/little-vm-helper action to v0.0.17 Signed-off-by: renovate[bot] <bot@renovateapp.com> 01 April 2024, 17:41:21 UTC
a09e401 Julian Wiedmann 26 March 2024, 18:44:35 UTC workflows: ipsec-e2e: clean up escaping artifacts Looks like these are no longer needed, and potentially cause breakage for the workflow. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> 26 March 2024, 19:44:29 UTC
cdf043a Tim Horner 26 March 2024, 19:29:11 UTC install: Update image digests for v1.13.14 Generated from https://github.com/cilium/cilium/actions/runs/8441668895. `docker.io/cilium/cilium:v1.13.14@sha256:75fc1088eec85faf2393552990bc1ecf457f32413b859a54e76a4b03bc001669` `quay.io/cilium/cilium:v1.13.14@sha256:75fc1088eec85faf2393552990bc1ecf457f32413b859a54e76a4b03bc001669` `docker.io/cilium/clustermesh-apiserver:v1.13.14@sha256:9c75b6c01990c740b052fa7abcd5467f2e8a7d064ee351779daac9132448b6bb` `quay.io/cilium/clustermesh-apiserver:v1.13.14@sha256:9c75b6c01990c740b052fa7abcd5467f2e8a7d064ee351779daac9132448b6bb` `docker.io/cilium/docker-plugin:v1.13.14@sha256:5793e142d74aaf15e051066722f27b716af05f81c17551251303739c4579d6a4` `quay.io/cilium/docker-plugin:v1.13.14@sha256:5793e142d74aaf15e051066722f27b716af05f81c17551251303739c4579d6a4` `docker.io/cilium/hubble-relay:v1.13.14@sha256:51279d0c92f1468dd4a3b4ead091bded03b4bfd8477eb6bae2c50e715bb32679` `quay.io/cilium/hubble-relay:v1.13.14@sha256:51279d0c92f1468dd4a3b4ead091bded03b4bfd8477eb6bae2c50e715bb32679` `docker.io/cilium/operator-alibabacloud:v1.13.14@sha256:124fc5b48c431f3051d94569cc4c764ee40d7cd4654f283b2c86ade935f3f1ec` `quay.io/cilium/operator-alibabacloud:v1.13.14@sha256:124fc5b48c431f3051d94569cc4c764ee40d7cd4654f283b2c86ade935f3f1ec` `docker.io/cilium/operator-aws:v1.13.14@sha256:579de91ac57aa17a6915c026cdd675d851d54bd89bbcf4867c80b21e38fedf03` `quay.io/cilium/operator-aws:v1.13.14@sha256:579de91ac57aa17a6915c026cdd675d851d54bd89bbcf4867c80b21e38fedf03` `docker.io/cilium/operator-azure:v1.13.14@sha256:b6761b5f24c88c8f86e091da43960be6bbbb7cffaaf4446c63c1bf995fedb3bc` `quay.io/cilium/operator-azure:v1.13.14@sha256:b6761b5f24c88c8f86e091da43960be6bbbb7cffaaf4446c63c1bf995fedb3bc` `docker.io/cilium/operator-generic:v1.13.14@sha256:d4112d05620f8db5d4219b7260b035048483cea49936bd55ddb5b81e1e559e2c` `quay.io/cilium/operator-generic:v1.13.14@sha256:d4112d05620f8db5d4219b7260b035048483cea49936bd55ddb5b81e1e559e2c` `docker.io/cilium/operator:v1.13.14@sha256:ebb52050d7cdc943c66901dfe0a42d639516967b836bf5014db93d5d714c7967` `quay.io/cilium/operator:v1.13.14@sha256:ebb52050d7cdc943c66901dfe0a42d639516967b836bf5014db93d5d714c7967` Signed-off-by: Tim Horner <timothy.horner@isovalent.com> 26 March 2024, 19:39:15 UTC
514c397 Tim Horner 26 March 2024, 16:46:06 UTC Prepare for release v1.13.14 Signed-off-by: Tim Horner <timothy.horner@isovalent.com> 26 March 2024, 17:39:05 UTC
400c112 Paul Chaignon 20 March 2024, 21:08:44 UTC node: Log local boot ID We have very little logging of the boot IDs. Really fixing that will require a bit of work to not be too verbose, but in the meantime, we should at least log the local boot ID. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
a652c12 Robin Gögge 20 March 2024, 16:18:34 UTC ipsec: fix per-node-pair-key computation This commit ensures that - each time we compute a per-node-pair-key we create an empty slice with the correct length first, and then append all the input data instead of appending to one of the input slices (`globalKey`) directly. - the IPs that are used as arguments in `computeNodeIPsecKey` are canonical, meaning IPv4 IPs consist of 4 bytes and IPv6 IPs consist of 16 bytes. This is necessary to always have the same inputs on all nodes when computing the per-node-pair-key. Without this IPs might not match on the byte level, e.g on one node the input is a v6 mapped v4 address (IPv4 address in 16 bytes) and on the other it isn't when used as input to the hash function. This will generate non-matching keys. Co-authored-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Robin Gögge <r.goegge@gmail.com> 26 March 2024, 13:54:47 UTC
5b04f09 Robin Gögge 20 February 2024, 16:27:44 UTC ipsec: disallow empty bootid for key generation [ notes: before v1.15, enableIPsecIPv4 and enableIPsecIPv6 didn't return an error. This needed to be changed from the original commit ] A node update that doesn't contain a BootID will cause the creation of non-matching XFRM IN and OUT states across the cluster as the BootID is used to generate per-node key pairs. Non-matching XFRM states will result in XfrmInStateProtoError, causing packet drops. An empty BootID should thus be treated as an error, and Cilium should not attempt to derive per-node keys from it. Signed-off-by: Robin Gögge <r.goegge@gmail.com> 26 March 2024, 13:54:47 UTC
f0f2afb Robin Gögge 12 March 2024, 13:35:46 UTC k8s: bump CRD schema version When adding the BootID field to the CiliumNode CRD we forgot to bump the version, which is an issue when after an cilium upgrade the operator tries to update the CiliumNode objects to include the BootID field. Signed-off-by: Robin Gögge <r.goegge@gmail.com> 26 March 2024, 13:54:47 UTC
3ed4fab Paul Chaignon 13 February 2024, 15:32:46 UTC workflows: Extend IPsec key rotation coverage [ backporter's notes: major conflict because we have a special case on v1.13 to handle the case where IPv6 is disabled. We therefore need to account for both IPv6 and the key-system when computing the expected number of keys. ] Since commit 4cf468b91b ("ipsec: Control use of per-node-pair keys from secret bit"), IPsec key rotations can be used to switch from the single-key system to the per-tunnel key system (also referred to as per-node-pair key system). Our key rotation test in CI was updated to cover such a switch. This commit extends it to also cover traditional key rotations, with both the new and old key systems. The switch back into a single-key system is also covered. These special key rotations are controlled with a single + sign. Adding it after the SPI in the IPsec Kubernetes secret is enough to switch to a per-tunnel key system. We thus simply need to cover all 4 cases of having or not having the + sign in the old and new secrets. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
92f90d8 Paul Chaignon 08 January 2024, 09:35:39 UTC ipsec: Control use of per-node-pair keys from secret bit [ backporter's notes: Minor conflicts in conformance-ipsec-e2e.yaml due to the extension of CI to cover non-AEAD keys. Minor conflict in the documentation for how to retrieve the SPI from the secret. The testing logic for the number of IPsec keys to expect also needed to be adjusted. On v1.13, we have one case where IPv6 is disabled. In that case, the number of expected keys per remote node drops from two to one (i.e., one per IP family). ] The ESN bit in the IPsec secret will be used to indicate whether per-node-pair keys should be used or if the global key should remain in use. Specifically, it consist in a '+' sign after the SPI number in the secret. This ESN bit will be used to transition from a global key system to a per-node-pair system at runtime. We would typically rely on an agent flag for such a configuration. However, in this case, we need to perform a key rotation at the same time as we change the key system. Encoding the key system in the IPsec secret achieves that. By transition from the global to the per-node-pair keys via a key rotation, we ensure that the two can coexist during the transition. The old, global key will have XFRM rules with SPI n, whereas the new, per-node-pair keys will have XFRM rules with SPI n+1. Using a bit in the IPsec secret is also easier to test because we already have all the logic to test key rotation (whereas we would need new logic to test a flag change). The users therefore need to perform a key rotation from e.g.: 3 rfc4106(gcm(aes)) [...] 128 to: 4+ rfc4106(gcm(aes)) [...] 128 The key rotation test in CI is updated to cover a rotation from 3 to 4+ (meaning a rotation into the new per-node-pair key system). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
568470b Nikolay Aleksandrov 08 January 2024, 09:35:39 UTC ipsec: Enable ESN anti-replay protection Now we can enable ESN anti-replay with window size of 1024. If a node reboots then everyone updates the related keys with the new one due to the different bootid, the node itself is already generating the keys with the new bootid. The window is used to allow for out-of-order packets, anti-replay still doesn't allow to replay any packet but keeps a bitmap and can accept out-of-order packets within window size range. For more information check section ""A2. Anti-Replay Window" of RFC 4303. Signed-off-by: Nikolay Aleksandrov <nikolay@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Co-authored-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
ab8beea Nikolay Aleksandrov 08 January 2024, 09:35:39 UTC docs: Document Xfrm{In,Out}NoStates on node reboots [ backporter's notes: Minor conflict due to a new error being listed in text that is now removed. ] When a node reboots the key used to communicate with it is expected to change due to the new boot id generated. While the new key is being installed we may need to do it non-atomically (delete + insert), so packets to/from that node might be dropped which would cause increases in the XfrmNoStatesIn/Out. Add a note about it in the docs so users are not surprised. Signed-off-by: Nikolay Aleksandrov <nikolay@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Co-authored-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
5d87123 Nikolay Aleksandrov 08 January 2024, 09:35:38 UTC ipsec: Update existing states when a node's bootid changes [ backporter's notes: Many conflicts due to the new error handling in main. ] When we detect that a node's bootid has changed, we need to update the IPsec states. Unfortunately this is not as straightforward as it should be, because we may receive the new boot ID before a CiliumInternalIP is assign to the node. In such a case, we can't install the XFRM states yet because we don't have the CiliumInternalIP, but we need to remember that the boot ID changed and states should be replaced. We therefore record that information in a map, ipsecUpdateNeeded, which is later read to see if the boot ID changed. Signed-off-by: Nikolay Aleksandrov <nikolay@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Co-authored-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
66192ae Nikolay Aleksandrov 08 January 2024, 09:35:38 UTC ipsec: Use boot IDs when deriving per-node keys [ backporter's notes: Minor conflicts due to new error handling in main. ] We need to ensure we never have two packets encrypted with the same key and sequence number. To that end, in previous commits, we introduced per-node-pair keys. That is however not sufficient. Since the sequence numbers can start from zero on node boot, if a node reboot, it will start sending traffic encrypted again with the same key and sequence number as it did before. To fix that, we need to ensure the per-node-pair keys change on node reboots. We achieve that by using the boot ID in the per-node-pair key calculation. For a pair of nodes A and B with IP addresses a and b and boot IDs x and y, we will therefore install two different keys: Node A <> Node B XFRM IN: key(b+a+y+x) XFRM IN: key(a+b+x+y) XFRM OUT: key(a+b+x+y) XFRM OUT: key(b+a+y+x) This is done such that, for each pair of nodes A, B, the key used for decryption on A (XFRM IN) is the same key used for encryption on B (XFRM OUT), and vice versa. Since we are now retrieving the local node's boot ID as part of the IPsec code, we need to initialize the mocked local node store in the unit tests. Signed-off-by: Nikolay Aleksandrov <nikolay@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Co-authored-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
42dfd25 Nikolay Aleksandrov 08 January 2024, 09:35:37 UTC k8s, node: Add bootid to CiliumNode resource [ backporter's comments: Non-trivial conflicts due to refactoring around local node initialization logic. ] Read and export the local bootid via CiliumNode. We'll need it in a subsequent commit to generate new IPsec keys when a node reboots. This commit also collects the boot_id file as part of the bugtool report. Signed-off-by: Nikolay Aleksandrov <nikolay@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Co-authored-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
fa978d8 Paul Chaignon 08 January 2024, 09:35:37 UTC ipsec: Allow old and new XFRM IN states to coexist for upgrade [ backporter's comments: Minor conflict due to new error handling in main. ] This commit extends the logic from commit c0d9b8c9e ("ipsec: Allow old and new XFRM OUT states to coexist for upgrade") to have both the old and the new XFRM IN states in place. This is necessary to avoid packet drops during the upgrade. As with the XFRM OUT states, we can't add the new IN state while the old one is in place. We therefore need to first remove the old state, to then add the new one. See c0d9b8c9e ("ipsec: Allow old and new XFRM OUT states to coexist for upgrade") for details. Note this commit also removes the comparison of output-marks. Output-marks aren't actually used by the kernel to decide if two states conflict. And in the case of XFRM IN states, the output-marks changed a bit as well. Despite being different, the states still conflict. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
c369979 Paul Chaignon 08 January 2024, 09:35:37 UTC ipsec: Per-node XFRM IN states [ backporter's comments: Many conflicts due to the new error handling in main. ] We want to have one IPsec key per node1->node2 (not including node2->node1 which will get a different key). We therefore need per-node XFRM states on the receive/decrypt side to carry each node's key. This commit implements that change. Thus, instead of creating a unique XFRM IN state when we receive the local node, we will create an XFRM IN state everytime we receive a remote node. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
a5bf920 Paul Chaignon 08 January 2024, 09:35:36 UTC ipsec, bpf: Match XFRM IN states using mark instead of source IP [ backporter's comments: Many conflicts. Some trivial due to new files with logs in sources_name_to_ids.h. Some minor in ipsec_linux.go due to the new error handling in main. Remove unnecessary include of lib/ipcache.h in BPF unit tests; that file doesn't exist before v1.15. ] It turns out that two XFRM IN states can't have the same mark and destination IP, even if they have different source IPs. That's an issue in our case because each node1->node2 pair will have its own IPsec key. Therefore, we need one XFRM state per origin node on input. Since we can't differentiate those XFRM states by their source IPs, we will have to differentiate using the marks. To do so, we need to convert the source IP into a packet mark before matching against XFRM states. We can write these packet marks in bpf_network, before going up the stack for decryption. And conveniently, we've just introduce a way to convert each cluster node into an ID, the node ID, which fits in the packet mark. This commit therefore performs an node ID map lookup to retrieve the node ID using the outer source IP address when packets are first processed in bpf_network. We clear the node ID from the packet mark after decryption using XFRM (output-mark). If no node ID is found for the outer source IP, we drop the packet. It seems preferable to drop it from BPF with all the contextual information rather than let it proceed to the XFRM layer where it will be dropped with only an error code incrementing. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
8a4e17e Paul Chaignon 08 January 2024, 09:35:36 UTC ipsec: Replace states with the old IPsec key In the previous commit, we changed the way we compute the IPsec keys. We therefore need to replace the XFRM states to use the new keys. Our current update logic however doesn't take this case into account. It compares states based on IPs, marks, and SPIs, but it doesn't compare the keys. It would therefore assume that the correct states are already installed. This commit extends that logic to detect a difference in encryption keys and, if such a difference exist, remove the old states. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
2cbd11b Paul Chaignon 08 January 2024, 09:35:36 UTC ipsec: Compute per-node-pair IPsec keys [ backporter's comments: Trivial conflict in conformance-ipsec-e2e.yaml for the number of expected keys. ] We need to ensure the (key used, sequence number) tuple for each encrypted packet is always unique on the network. Today that's not the case because the key is the same for all nodes and the sequence number starts at 0 on node reboot. To enable this, we will derive one key per node pair from a global key shared across all nodes. We need it per node pair and not per node because the first message emitted from A to B shouldn't be using the same key as the first message emitted from B to A, to satisfy the above requirement. To that end, for each node pair (A, B), we compute a key as follows: key = sha256(global_key + ip_of_a + ip_of_b) The sha256 sum is then truncated to the expected length. Once computed, we install the derived keys such that the key used for encryption on node A is the same as the key used for decryption on node B: Node A <> Node B XFRM IN: key(b+a) XFRM IN: key(a+b) XFRM OUT: key(a+b) XFRM OUT: key(b+a) Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
9c40d17 Paul Chaignon 08 January 2024, 09:35:36 UTC ipsec: Move enableIPsecIPv{4,6} preconditions to caller [ backporter's notes: Small conflicts due to the new error handling in main. ] This small bit of refactoring will ease a subsequent commit. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
1846ca9 Paul Chaignon 08 January 2024, 09:35:35 UTC ipsec: New IPsec secret bit to indicate per-node-pair keys Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
2e8dc46 Paul Chaignon 21 December 2023, 14:17:33 UTC conn-disrupt: Allowlist XfrmInNoStates packet drops [ backporter's notes: Minor conflict due to structural changes in the GitHub Action (switched how we execute into LVH). ] The IPsec fixes will introduce a few XfrmInNoStates packet drops on up/downgrades due to non-atomic Linux APIs (can't replace XFRM states atomically). Those are limited to a very short time (time between two netlink syscalls). We however need to allowlist them in the CI. Since we're using the conn-disrupt GitHub action from main, we need to allowlist in main for the pull request's CI to pass. Note that despite the expected-xfrm-errors flag, the tests will still fail if we get 10 or more such drops. We don't expect so many XfrmInNoStates drops so we still want to fail in that case. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 26 March 2024, 13:54:47 UTC
e68dbb3 Marco Hofstetter 19 March 2024, 13:48:13 UTC cilium-dbg: listing load-balancing configurations displays L7LB proxy port [ upstream commit d3b19d65d3358c1dc08d55e715219a74567cd26d ] Currently, listing the load-balancing configuration doesn't display the L7LB Proxy Port for services of type `l7-load-balancer`. ``` cilium-dbg bpf lb list SERVICE ADDRESS BACKEND ADDRESS (REVNAT_ID) (SLOT) ... 10.96.193.7:443 0.0.0.0:0 (30) (0) [ClusterIP, non-routable, l7-load-balancer] ``` The only way of retrieving the L7LB proxy port is to list the frontends (`cilium-dbg bpf lb list --frontends`) and manually convert the backend id (union type) to the L7LB proxy port. Therefore, this commit addsd the L7LB proxy port to the output of `cilium-dbg bpf lb list` if the service is of type L7 LoadBalancer. The `--frontends` subcommand still displays the unmapped backend id. ``` cilium-dbg bpf lb list SERVICE ADDRESS BACKEND ADDRESS (REVNAT_ID) (SLOT) 10.96.0.1:443 172.18.0.3:6443 (1) (1) 0.0.0.0:0 (1) (0) [ClusterIP, non-routable] 10.96.252.10:443 172.18.0.2:4244 (22) (1) 0.0.0.0:0 (22) (0) [ClusterIP, InternalLocal, non-routable] 10.96.155.44:80 0.0.0.0:0 (14) (0) [ClusterIP, non-routable] 10.244.1.211:80 (14) (1) 172.18.0.2:32646 0.0.0.0:0 (33) (0) [NodePort, l7-load-balancer] (L7LB Proxy Port: 15735) 10.96.193.7:443 0.0.0.0:0 (30) (0) [ClusterIP, non-routable, l7-load-balancer] (L7LB Proxy Port: 15735) 10.96.122.45:80 10.244.1.250:80 (26) (1) 0.0.0.0:0 (26) (0) [ClusterIP, non-routable] 10.96.102.137:80 0.0.0.0:0 (23) (0) [ClusterIP, non-routable] 10.244.1.126:4245 (23) (1) 10.96.108.180:443 0.0.0.0:0 (17) (0) [ClusterIP, non-routable, l7-load-balancer] (L7LB Proxy Port: 17731) 172.18.255.1:80 0.0.0.0:0 (25) (0) [LoadBalancer, l7-load-balancer] (L7LB Proxy Port: 17731) 0.0.0.0:32646 0.0.0.0:0 (34) (0) [NodePort, non-routable, l7-load-balancer] (L7LB Proxy Port: 15735) 0.0.0.0:31012 0.0.0.0:0 (21) (0) [NodePort, non-routable, l7-load-balancer] (L7LB Proxy Port: 17731) ``` Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 25 March 2024, 13:28:59 UTC
d3ffeb7 David Bimmler 19 March 2024, 14:10:10 UTC AKS: avoid overlapping pod and service CIDRs [ upstream commit fbe78c42f44f8e1c04d3886fc51a2b283b668770 ] The default service CIDR of AKS clusters is 10.0.0.0/16 [1]. Unfortunately, we don't set a pod cidr for clusterpool IPAM, and hence use cilium's default of 10.0.0.0/8, which overlaps. This can lead to "fun" situations in which e.g. the kube-dns service ClusterIP is the same as the hubble-relay pod IP, or similar shenanigans. This usually breaks the cluster utterly. The fix is relatively straight-forward: set a pod CIDR for cilium which does not overlap with defaults of AKS. We chose 192.168.0.0/16 as this is what is recommended in [2]. [1]: https://learn.microsoft.com/en-us/azure/aks/configure-kubenet#create-an-aks-cluster-with-system-assigned-managed-identities [2]: https://learn.microsoft.com/en-us/azure/aks/azure-cni-powered-by-cilium#option-1-assign-ip-addresses-from-an-overlay-network Fixes: fbf3d38a4b (ci: add AKS workflow) Co-authored-by: Fabian Fischer <fabian.fischer@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 25 March 2024, 13:28:59 UTC
5296a8b renovate[bot] 25 March 2024, 07:02:33 UTC chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> 25 March 2024, 10:50:17 UTC
d559f1d Alexandre Perrin 06 March 2024, 19:06:43 UTC hubble: fix traffic direction and reply on encrypted trace notifications [ upstream commit 9939fa2b0848ddd056e81f14a548f179f59027f3 ] [ backporter notes: No SRV6 support on v1.13, I removed those test cases ] Before this patch, Hubble would wrongly report known traffic direction and reply status when IPSec was enabled. Signed-off-by: Alexandre Perrin <alex@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
593aad5 Paul Chaignon 17 March 2024, 17:05:08 UTC docs: Warn on key rotations during upgrades [ upstream commit b639eab46a1fd85f0bab362b3fdf4cf21df80ace ] In general, it is not recommended to carry several admin. operations on the cluster at the same time, as it can make troubleshooting in case of issues a lot more complicated. Mixing operations is also less likely to be covered in CI so more likely to hit corner cases. Performing IPsec key rotations during Cilium up/downgrades is one such case. Let's document it explicitly to discourage users from doing that. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
551689d Marco Iorio 15 March 2024, 13:59:39 UTC gha: disable fail-fast on integration tests [ upstream commit 0fb203e8671638bad22438ec31cbe687462c4826 ] So that the failure of one matrix entry (e.g., caused by a flake) doesn't cancel the other ongoing tests, if any. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
e3226e1 Tam Mach 10 March 2024, 03:42:39 UTC gateway-api: Retrieve LB service from same namespace [ upstream commit e8bed8d8343731422dc65b706c3617a40d0a8058 ] [ backporter notes: conflicts in unit tests. Had to change introduce the `NoError` check instead of expecting a specific error ] This commit is to add the same namespace while listing generated LB service, the main reason is to avoid wrong status update for gateways having the same name, but belonged to different namespace. Testing was done locally as per below: Before the fix: ``` $ kg gateway -A NAMESPACE NAME CLASS ADDRESS PROGRAMMED AGE another my-gateway cilium 10.110.222.237 True 4s default my-gateway cilium 10.110.222.237 True 56s ``` After the fix: ``` $ kg gateway -A NAMESPACE NAME CLASS ADDRESS PROGRAMMED AGE another my-gateway cilium 10.102.170.180 True 14m default my-gateway cilium 10.110.222.237 True 14m $ kg services -A NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE another cilium-gateway-my-gateway LoadBalancer 10.102.170.180 10.102.170.180 80:31424/TCP 15m default cilium-gateway-my-gateway LoadBalancer 10.110.222.237 10.110.222.237 80:31889/TCP 15m ... ``` Fixes: https://github.com/cilium/cilium/issues/31270 Signed-off-by: Tam Mach <tam.mach@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
7109004 Tom Hadlaw 21 July 2023, 17:52:28 UTC ipam: fix azure ipam test panics due to shared pointers. [ upstream commit 1ca6141190f455cae85ebe6215f86a74bda9d213 ] pkg/ipam/types.(*InstanceMap).DeepCopy(...) will iterate for all instances/interfaces in order to copy the data. However, unlike what the name suggests, underlying instance pkg/ipam/types.Interface pointers are copied and shared in the returned instance map. In some cases, this case result in memory corruption issues resulting in confusing panics while running tests such as: ``` panic: runtime error: makeslice: cap out of range goroutine 1366 [running]: strconv.appendQuotedWith({0xc000576208, 0x0, 0x3f?}, {0x1000000, 0x100000001000000}, 0x22, 0x0, 0x0) /opt/hostedtoolcache/go/1.22.0/x64/src/strconv/quote.go:35 +0x85 strconv.AppendQuote(...) ... ``` Capturing such an event in a debugger you would see a AzureInterface struct such as this with the IP string memory being corrupt (likely due to an interleaved read/write) being passed to logrus causing a crash. ``` github.com/cilium/cilium/pkg/azure/types.AzureAddress { IP: "\x10\x01\x00\x00\x00\x00\x00\x00\x10\x01\x00\x00\x00\x00\x00\x007d�_\x02\b\b\x19\x00\x00\x00\x00\x00\x00\x00\x00�\x1f�\x03\x00\x00\x00\x00W�\b\x00\x00\x00\x00\x00\x00p \x03\x00\x00\x00\x00�qi\x03\x00\x00\x00\x00...+51559946186908214 more", Subnet: "subsys", State: "instanceID",} ``` This ensures that the revision interface is correctly deepcopied such that the underlying resource is also safely copied. Fixed: #31059 Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
00bb27b Yutaro Hayakawa 14 March 2024, 04:32:32 UTC ci: Bump lvh-kind ssh-startup-wait-retries [ upstream commit a5eafe025390d77fa370add4883e6b1a00da7365 ] Recently, we frequently see the CI failure with lvh-kind startup failure with exit code 41. This indicates the timeout of the task waiting for the SSH startup. Bump the timeout (retry) to 600 (10min) as a workaround. Fixes: #31336 Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
0287e8a Philip Schmid 13 March 2024, 09:47:02 UTC doc: Clarified GwAPI KPR prerequisites [ upstream commit 1321e03093db0f7655488c60f91e22e273c65cb0 ] [ backporter notes: Adjusted wording for v1.13 ] Before the GwAPI doc listed KPR mode as a prerequisite. However, it's actually only required to enable BPF nodePort support. Signed-off-by: Philip Schmid <philip.schmid@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
e639781 Hemanth Malla 28 February 2024, 21:31:30 UTC Adding unit test for PD fallback [ upstream commit 0007e35d0a5de7b570e4750cb12a7965b3301949 ] [ backporter notes: Minor import conflict in pkg/aws/ec2/mock/mock.go and replaced `Upsert` with `Update` in node_manager_test.go ] Signed-off-by: Hemanth Malla <hemanth.malla@datadoghq.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
51db4fa Hemanth Malla 27 February 2024, 21:38:58 UTC Handle InvalidParameterValue as well for PD fallback [ upstream commit 5a487b59a5b9cbc52dd221885655c6cb8abd1890 ] cilium#30536 prematurely concluded that AWS now uses InsufficientCidrBlocks to indicate the subnet is out of prefixes. Looks like AWS still uses InvalidParameterValue and "There aren't sufficient free Ipv4 addresses or prefixes" to indicate subnet is at capacity. In addition to this InsufficientCidrBlocks is returned when subnet is at capacity potentially due to fragmentation. In either case, it's worth trying to fallback since /32 IPs might still be available compared to /28. See PR for details from AWS support ticket. Signed-off-by: Hemanth Malla <hemanth.malla@datadoghq.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 21 March 2024, 13:30:51 UTC
2765b27 Tobias Klauser 15 March 2024, 15:01:10 UTC k8s/utils: correctly filter out labels in StripPodSpecialLabels [ upstream commit 280b69d9c12da757bfa764e3e77b87660f77c5bc ] Filter the labels before iterating them, otherwise they are added to sanitizedLabels again. Also remove forbidden keys prefixed with io.cilium.k8s because they are already filtered out by filterPodLabels and inline the check for kubernetes namespace labels. Fixes: ed4e6505c059 ("k8s/utils: filter out cilium-owned labels on pod update") Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
2253ef2 Tobias Klauser 14 March 2024, 16:46:06 UTC k8s/utils: filter out cilium-owned labels on pod update [ upstream commit ed4e6505c059512446d45b40d5aba6ca5cf15d3c ] Currently `io.cilium.k8s.*` pod labels are only filtered out on pod creation. On pod update, they are currently not filtered which leads to a situation where no pod label update is reflected in the endpoint anymore in case of a `io.cilium.k8s.*` label set on the pod: $ cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: foo namespace: default labels: app: foobar io.cilium.k8s.something: bazbar spec: containers: - name: nginx image: nginx:1.25.4 ports: - containerPort: 80 EOF $ kubectl -n kube-system exec -it cilium-nnnn -- cilium-dbg endpoint list ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS ENFORCEMENT ENFORCEMENT 252 Disabled Disabled 50316 k8s:app=foobar fd00:10:244:1::8b69 10.244.1.78 ready k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.cilium.k8s.policy.cluster=kind-kind k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default $ kubectl label pods foo app=nothing --overwrite $ kubectl describe pod foo [...] Labels: app=nothing io.cilium.k8s.something=bazbar [...] $ kubectl describe cep foo [...] Labels: app=foobar io.cilium.k8s.something=bazbar [...] $ kubectl -n kube-system exec -it cilium-nnnn -- cilium-dbg endpoint list ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS ENFORCEMENT ENFORCEMENT 252 Disabled Disabled 50316 k8s:app=foobar fd00:10:244:1::8b69 10.244.1.78 ready k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.cilium.k8s.policy.cluster=kind-kind k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default 1285 Disabled Disabled 1 reserved:host ready 1297 Disabled Disabled 4 reserved:health fd00:10:244:1::ebfb 10.244.1.222 ready Note that the `app` label didn't change from `foobar` to `nothing` in the endpoint and the CiliumEndpoint CRD This is because the filtered labels are passed wrongly passed to `(*Endpoint).ModifyIdentityLabels` which in turn calls `e.OpLabels.ModifyIdentityLabels` which checks whether all of the deleted labels (which contains the filtered label on pod update for the example above) were present before, i.e. on pod creation. This check fails however because the labels were filtered out on pod creation. Fix this issue by also filtering out the labels on pod update and thus allowing the label update to successfully complete in the presence of filtered labels. After this change, the labels are correctly updated on the endpoint and the CiliumEndpoint CRD: $ kubectl label pods foo app=nothing --overwrite $ kubectl describe pod foo [...] Labels: app=nothing io.cilium.k8s.something=bazbar [...] $ kubectl describe cep foo [...] Labels: app=nothing io.cilium.k8s.something=bazbar [...] $ kubectl -n kube-system exec -it cilium-x2x5r -- cilium-dbg endpoint list ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS ENFORCEMENT ENFORCEMENT 57 Disabled Disabled 56486 k8s:app=nothing fd00:10:244:1::71b7 10.244.1.187 ready k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.cilium.k8s.policy.cluster=kind-kind k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default 201 Disabled Disabled 4 reserved:health fd00:10:244:1::c8de 10.244.1.221 ready 956 Disabled Disabled 1 reserved:host ready Fixes: 599dde3b91b3 ("k8s: Filter out cilium owned from pod labels") Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
ec0cce6 Tobias Klauser 14 March 2024, 16:16:37 UTC k8s/watchers: set unfiltered pod labels on CEP on pod update [ upstream commit 5508746586091ffa2c72e24362ec62781a4ce2ad ] The labels on the CEP are set to the unfiltered pod labels on CEP creation, see [1]. On any label update where labels contain filtered labels, e.g. io.cilium.k8s.* labels or labels filtered out by the user by means of the --label and/or --label-prefix-file agent options the current logic would wrongly remove the filtered labels from the CEP labels. Fix this by always using the unfiltered pod labels. [1] https://github.com/cilium/cilium/blob/b58125d885edbb278f11f84303c0e7c934ca7ea4/pkg/endpointmanager/endpointsynchronizer.go#L185-L187 Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
332f70f Tobias Klauser 14 March 2024, 16:45:07 UTC k8s: move filterPodLabels to k8s/utils package for SanitizePodLabels [ upstream commit 23098051f1994e5ac69d181680556de28c3e5540 ] Currently GetPodMetadata is the only caller of SanitizePodLabels but other callers will be introduced in successive changes. This change ensures the io.cilium.k8s.* labels are filtered for these callers as well. Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
d672e98 Tobias Klauser 14 March 2024, 16:16:32 UTC k8s/watchers: warn when endpoint label update fails on pod update [ upstream commit 9a26446df2acad3c03c2413aca4d95f1e9bd7406 ] Currently, failure to update endpoint labels based on pod labels on pod update is silently ignored by the callers or only reflected in error count metrics. Report a warning to clearly indicate that pod and endpoint labels might be out of sync. Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
54fd040 Tobias Klauser 14 March 2024, 16:16:29 UTC k8s/watchers: inline single-use updateEndpointLabels [ upstream commit bba0ff569e10e902747ae8df0761f96374a10f5f ] The functions updateEndpointLabel is only used in one place. Inline it to improve readability and simplify changes in successive commits. Signed-off-by: Tobias Klauser <tobias@cilium.io> 20 March 2024, 06:58:42 UTC
e86b395 Cilium Imagebot 19 March 2024, 09:43:40 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 19 March 2024, 21:20:24 UTC
98dae53 renovate[bot] 19 March 2024, 09:37:25 UTC chore(deps): update docker.io/library/golang:1.21.8 docker digest to 8560736 Signed-off-by: renovate[bot] <bot@renovateapp.com> 19 March 2024, 21:20:24 UTC
f2ad82d renovate[bot] 19 March 2024, 09:37:34 UTC chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> 19 March 2024, 13:31:06 UTC
0bb579b Ryan Drew 27 February 2024, 17:42:57 UTC bpf: Enable monitor aggregation for all events in bpf_network.c [ upstream commit 81f14bbd4ebe898c48a918822ed30fe42ed5620d ] This commit adjusts the usage of send_trace_notify in bpf_network.c to enable monitor aggregation for all events emitted at this observation point in the datapath. This change helps improve resource usage by reducing the overall number of events that the datapath emits, while still enabling packet observability with Hubble. The events in bpf_network.c enable observability into the IPSec processing of the datapath. Before this commit, multiple other efforts have been made to increase the aggregation of events related to IPSec to reduce resource usage, see #29616 and #27168. These efforts were related to packets that were specifically marked as encrypted or decrypted by IPSec and did not include events in bpf_network.c that were emitted when either: (a) a plaintext packet has been received from the network, or (b) a packet was decrypted and reinserted into the stack by XFRM. Both of these events are candidates for aggregation because similar to-stack events will be emitted down the line in the datapath anyways. Additionally, these events are mainly useful for root-cause analysis or debugging and are not necessarily helpful from an overall observability standpoint. Signed-off-by: Ryan Drew <ryan.drew@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
7531e09 André Martins 06 March 2024, 11:40:00 UTC introduce ARM github workflows [ upstream commit 7a301a48c55c427714261e0686699fc2f63d2d31 ] This commit adds the GH workflow to run on arm machines. This effectively means that we can remove our travis integration and only use GH actions from now on. Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
cebe45e Paul Chaignon 05 March 2024, 10:59:32 UTC cilium-dbg: New --stale flag for encrypt flush [ upstream commit 5eb27e25b38bc6d073e96835f674d0748176d49e ] [ backporter's note: replaced nodemap.LoadNodeMap() with the legacy nodemap.NodeMap().OpenOrCreate() ] [ backporter's note: changes applied to cilium/cmd/encrypt_flush.go rather than cilium-dbg/cmd/encrypt_flush ] This new flag will allow users to clean stale XFRM states and policies based on the node ID map contents. If XFRM states or policies are found with a node ID that is not in the BPF map, then we probably have a leak somewhere. Such leaks can lead in extreme cases to performance degradation when the number of XFRM states and policies grows large (and if using ENI or Azure IPAM). Having a tool to cleanup these XFRM states and policies until the leak is fixed can therefore be critical. The new flag is incompatible with the --spi and --node-id filter flags. We first dump the XFRM rules and then dump the map content. In that way, if a new node ID is allocated while we're running the tool, we will simply ignore the corresponding XFRM rules. If a node ID is removed while running the tool, we will fail to remove the corresponding XFRM rules and continue with the others. Tested on a GKE cluster by adding fake XFRM states and policies that the tool was able to remove. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
c73aa10 Paul Chaignon 05 March 2024, 10:57:50 UTC cilium-dbg: Refactor confirmation message for encrypt flush [ upstream commit 5c2a67fcd306329abb8f5be0a7bac753141bfea6 ] [ backporter's note: changes applied to cilium/cmd/encrypt_flush.go rather than cilium-dbg/cmd/encrypt_flush ] This commit refactors the code a bit simplify a latter commit. No functional changes. This may be a bit excessive in commit splitting, but at least I can claim my last commit is free of any refactoring :sweat_smile: Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
c1d924d Paul Chaignon 05 March 2024, 10:53:08 UTC cilium-dbg: Don't fatal on XFRM rule deletion errors [ upstream commit 927969b247ed8f8b499988274a23e8ca2da42346 ] [ backporter's note: changes applied to cilium/cmd/encrypt_flush.go rather than cilium-dbg/cmd/encrypt_flush ] This commit slightly changes the behavior of the "encrypt flush" command in case of errors when trying to delete XFRM rules. The tool currently lists rules, filters them based on user-given arguments, and then deletes them. If an XFRM rule is deleted by the agent or the user while we're filtering, the deletion will fail. The current behavior in that case is to fatal. On busy clusters, that might mean that we always fatal because XFRM states and policies are constently added and removed. This commit changes the behavior to proceed with subsequent deletions in case one fails. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
c1afdbc Tom Hadlaw 27 February 2024, 17:30:44 UTC cni: use default logger with timestamps. [ upstream commit a099bf1571f1a090ccfd6ccbba545828a6b3b63c ] [ backporter's node: changes applied to plugins/cilium-cni/main.go rather than plugins/cilium-cni/cmd/cmd.go ] Unlike runtime agent/operator logs, CNI logs are just written to disk so we have no way to attach timestamps to them. This makes it harder to debug CNI issues as we have no way to correlate when things happened between Agent logs and CNI events. This switches CNI to use the same default logger, except with timestamps enabled. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
0e97258 Tom Hadlaw 26 February 2024, 20:41:32 UTC loader: fix cancelled context during compile logging errors. [ upstream commit 70b405f32018af84ad8221e4bafb223a70c23736 ] [ backporter's note: replaced errors.Join with fmt.Errorf ] On Linux/Unix based implementations, exec/cmd.Run will return either context.ContextCancelled or the error "signal: killed" depending on whether the cancellation occurred while the process was running. There's several places we check on ```is.Errors(err, context.Cancelled)``` on whether to emit high level logs about failed program compilations. Because already running cmd.Run() doesn't return an error that satisfies this, this will result in spurious error logs about failed compilation (i.e. "signal: killed") This meant that in cases where a compilation is legitimately cancelled, we would still log an error such as msg="BPF template object creation failed" ... error="...: compile bpf_lxc.o: signal: killed" This can occur occasionally in CI, which enforces no error to pass, causing failures. example: ``` ctx, c := context.WithTimeout(context.Background(), time.Second) go func() { time.Sleep(time.Second) c() }() cmd := exec.CommandContext(ctx, "sleep", "2") fmt.Println(cmd.Run()) ctx, c = context.WithTimeout(context.Background(), time.Second) c() cmd = exec.CommandContext(ctx, "sleep", "2") fmt.Println(cmd.Run()) ``` To fix this, this will join in the ctx.Err() if it is: * context.Cancelled * The process has not exited itself. * The process appeared to be SIGKILL'ed. Addresses: #30991 Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 16 March 2024, 12:49:03 UTC
back to top