| 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 |
| ae1e87d | Marco Iorio | 14 March 2024, 15:53:15 UTC | node: correctly propagate source for CiliumInternalIP ipcache metadata Upon reception of a node update event, we first upsert the CiliumInternalIP address into the ipcache, and then associate it with the relevant metadata (i.e., labels) based on the identity. However, while the first upsertion propagates the source from the triggering event (e.g., custom-resource or kvstore), the latter hard-codes the source depending on the identity: local if ID=host, and custom-resource if ID=custom-resource. This hard-coded value is problematic in two main cases: * When kvstore is used, as the kvstore source has higher precedence than the custom-resource one. This means that the ipcache upsertion subsequently triggered by InjectLabels gets aborted as of lower priority, causing an increase in the ipcache_errors_total metric at best, and possible policies issues otherwise. * When --enable-remote-node-identity=false, that is remote node identities are disabled, remote nodes are associated with the host identity. Based on the hard-coded values mentioned above, the metadata is then associated with source=local. In turn, this will prevent any further updates for that node from the CRDs or kvstore from taking effect, as having lower priority. Hence, continuing to use stale information (e.g., tunnel endpoint and key ID) upon subsequent changes. Let's fix this by correctly propagating the source during metadata upsertion as well, matching the behavior of ipcache upsertion. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:46:41 UTC |
| 0e17ebb | Marco Iorio | 06 March 2024, 13:02:24 UTC | gha: checkout target branch instead of the default one [ upstream commit 6716a9c01b69d88da0c3316fe8b3640180bbafb1 ] Currently, the GHA workflows running tests triggered on pull_request and/or push events initially checkout the default branch to configure the environment variables, before retrieving the PR head. However, this is problematic on stable branches, as we then end up using the variables from the default (i.e., main) branch (e.g., Kubernetes version, Cilium CLI version), which may not be appropriate here. Hence, let's change the initial checkout to retrieve the target (i.e., base) branch, falling back to the commit in case of push events. This ensure that we retrieve the variables from the correct branch, and matches the behavior of Ariane triggered workflows. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:33:35 UTC |
| b6831d2 | Marco Iorio | 23 February 2024, 10:17:37 UTC | gha: don't wait for kind clusters to become ready [ upstream commit 39637d6d2385baab556078d844f431522d99f616 ] They will never, because no CNI is present at that point. Hence, let's just avoid wasting one minute waiting for the timeout to expire. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:33:35 UTC |
| 80bb011 | Marco Iorio | 22 February 2024, 17:20:43 UTC | gha: migrate workflows to use the global kind-related variables [ upstream commit aabdfa73d3d83edda3935277bd08c4c4c0bf5b68 ] Let's switch all the workflows over to using the globally defined kind-related variables, and remove the workflow specific definitions. This also addresses a few cases which didn't specify any version. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:33:35 UTC |
| 3e673e3 | Marco Iorio | 22 February 2024, 17:15:28 UTC | gha: centralize kind version and image definition in set-env-variables [ upstream commit 394b3de26a4e2235ec25399861e12886b507f335 ] [ backporter's notes: edited the KIND_K8S_IMAGE value to match the latest supported version in the v1.13 branch ] Let's define kind-related variables (i.e., version, k8s image and k8s version) inside the set-env-variables action. One all consumers will have been migrated through the subsequent commit, this will ensure consistency across workflows, simplify version bumps as well as the introduction of new workflows depending on them. One extra byproduct is that renovate updates will also stop requesting reviews from all the different teams owning each specific workflow. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:33:35 UTC |
| 120cb4c | Marco Iorio | 23 February 2024, 08:15:38 UTC | gha: drop unused check_url environment variable [ upstream commit e17cf21d9720493766c9f1d12c2d75c842f26e86 ] This variable used to be used in combination with the Sibz/github-status-action action, which we replaced with myrotvorets/set-commit-status-action when reworking the workflows to be triggered by Ariane [1]. Given it is now unused, let's get rid of the leftover environment variable, so that we also stop copying it to new workflows. [1]: 9949c5a1891a ("ci: rework workflows to be triggered by Ariane") Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> | 16 March 2024, 12:33:35 UTC |
| c6c14ae | Tim Horner | 14 March 2024, 23:39:30 UTC | install: Update image digests for v1.13.13 Generated from https://github.com/cilium/cilium/actions/runs/8287875693. `docker.io/cilium/cilium:v1.13.13@sha256:861772857f72bf9cf7b1bab95b3a3c5dc5de1c18c26cfffd4f4dea095ce1a59c` `quay.io/cilium/cilium:v1.13.13@sha256:861772857f72bf9cf7b1bab95b3a3c5dc5de1c18c26cfffd4f4dea095ce1a59c` `docker.io/cilium/clustermesh-apiserver:v1.13.13@sha256:9f7a4a3f696f43e170b28d16e0e98d3c9d53b6f6a634bcae4c049839f6fa001d` `quay.io/cilium/clustermesh-apiserver:v1.13.13@sha256:9f7a4a3f696f43e170b28d16e0e98d3c9d53b6f6a634bcae4c049839f6fa001d` `docker.io/cilium/docker-plugin:v1.13.13@sha256:d04a8d96204d8f32f46b7bbb9e9329fc82dbc9f8197eddc39cb10915c16c97d4` `quay.io/cilium/docker-plugin:v1.13.13@sha256:d04a8d96204d8f32f46b7bbb9e9329fc82dbc9f8197eddc39cb10915c16c97d4` `docker.io/cilium/hubble-relay:v1.13.13@sha256:19348701926a6c4a2e502e8aa185ffa147368ee1e93d2f4c9e1d451b9f81b153` `quay.io/cilium/hubble-relay:v1.13.13@sha256:19348701926a6c4a2e502e8aa185ffa147368ee1e93d2f4c9e1d451b9f81b153` `docker.io/cilium/operator-alibabacloud:v1.13.13@sha256:847301ce51b1e6c3f61adddbd051c7832847dcd1df0ed2d37d2262f4c73d9880` `quay.io/cilium/operator-alibabacloud:v1.13.13@sha256:847301ce51b1e6c3f61adddbd051c7832847dcd1df0ed2d37d2262f4c73d9880` `docker.io/cilium/operator-aws:v1.13.13@sha256:166c232bb82f211e0405c7bd52e3a4c5ffc70c4b6b7c1444e2d92b5eefb52abd` `quay.io/cilium/operator-aws:v1.13.13@sha256:166c232bb82f211e0405c7bd52e3a4c5ffc70c4b6b7c1444e2d92b5eefb52abd` `docker.io/cilium/operator-azure:v1.13.13@sha256:a78a74ff804d82189144505a40841426a40edd499dd2973aae163c6450d5df2c` `quay.io/cilium/operator-azure:v1.13.13@sha256:a78a74ff804d82189144505a40841426a40edd499dd2973aae163c6450d5df2c` `docker.io/cilium/operator-generic:v1.13.13@sha256:42ca3f1a6a5ca1312119418c98d8e2b989c56e2a979da3b8c1a0d1961a78e40c` `quay.io/cilium/operator-generic:v1.13.13@sha256:42ca3f1a6a5ca1312119418c98d8e2b989c56e2a979da3b8c1a0d1961a78e40c` `docker.io/cilium/operator:v1.13.13@sha256:58d909aa2c788c58392e54c0877948b632598493e37a46a91cc324ec5d297618` `quay.io/cilium/operator:v1.13.13@sha256:58d909aa2c788c58392e54c0877948b632598493e37a46a91cc324ec5d297618` Signed-off-by: Tim Horner <timothy.horner@isovalent.com> | 15 March 2024, 13:34:13 UTC |
| ca1af73 | Tim Horner | 13 March 2024, 15:45:55 UTC | Prepare for release v1.13.13 Signed-off-by: Tim Horner <timothy.horner@isovalent.com> | 13 March 2024, 21:52:50 UTC |
| a58e3f4 | André Martins | 12 March 2024, 13:33:25 UTC | images: update cilium-{runtime,builder} Signed-off-by: André Martins <andre@cilium.io> | 12 March 2024, 19:50:22 UTC |
| bade091 | André Martins | 12 March 2024, 13:03:33 UTC | images: bump cni plugins to v1.4.1 The result of running ``` images/scripts/update-cni-version.sh 1.4.1 ``` Signed-off-by: André Martins <andre@cilium.io> | 12 March 2024, 19:50:22 UTC |
| 5f086f7 | Cilium Imagebot | 11 March 2024, 08:47:16 UTC | images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> | 12 March 2024, 12:42:23 UTC |
| 7a03059 | renovate[bot] | 11 March 2024, 08:39:03 UTC | chore(deps): update docker.io/library/ubuntu:22.04 docker digest to 77906da Signed-off-by: renovate[bot] <bot@renovateapp.com> | 12 March 2024, 12:42:23 UTC |
| 57722a2 | renovate[bot] | 12 March 2024, 09:09:33 UTC | chore(deps): update hubble cli to v0.13.2 Signed-off-by: renovate[bot] <bot@renovateapp.com> | 12 March 2024, 12:41:49 UTC |
| a325017 | Feroz Salam | 11 March 2024, 15:48:05 UTC | Bump google.golang.org/protobuf (v1.13) Signed-off-by: Feroz Salam <feroz.salam@isovalent.com> | 11 March 2024, 21:23:45 UTC |
| 739e2f0 | renovate[bot] | 11 March 2024, 08:45:34 UTC | chore(deps): update stable lvh-images Signed-off-by: renovate[bot] <bot@renovateapp.com> | 11 March 2024, 13:34:48 UTC |
| 3956694 | renovate[bot] | 11 March 2024, 09:04:15 UTC | chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> | 11 March 2024, 13:33:34 UTC |
| 5d4789c | Paul Chaignon | 26 February 2024, 12:07:43 UTC | bugtool: Capture memory fragmentation info from /proc [ upstream commit 1c3a17f672f6da2332b3731329aead13b3c17e22 ] This information can be useful to understand why memory allocation in the kernel may fail (ex. for maps or for XFRM). I've checked that these two files are accessible from a typical cilium-agent deployment (on GKE). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> | 11 March 2024, 08:23:48 UTC |
| afca4ee | Dean | 26 January 2024, 13:11:44 UTC | Update kafka-sw-gen-traffic.sh [ upstream commit 7a5a4295f8ca75a21e57969ef01a4926641c2ce1 ] Fixed `kubectl exec` syntax Signed-off-by: Dean <22192242+saintdle@users.noreply.github.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> | 11 March 2024, 08:23:48 UTC |
| 501b20d | André Martins | 06 March 2024, 09:09:14 UTC | k8s_install.sh: specify the CNI version [ upstream commit f92b528abc30a5c66ba80d5922d4e58c48cfe7e1 ] The CNI version should be specify so that in case we have to fallback the installation of k8s via binaries it doesn't fail with the error: ``` 10:29:25 k8s1-1.25: gzip: stdin: not in gzip format 10:29:25 k8s1-1.25: tar: Child returned status 1 10:29:25 k8s1-1.25: tar: Error is not recoverable: exiting now ``` Fixes: ce69afdc3ad1 ("add support for k8s 1.25.0") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 08 March 2024, 12:16:21 UTC |
| 317016f | Tam Mach | 07 March 2024, 13:30:35 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/bbde4095997ea57ead209f56158790d47224a0f5 Related build: https://github.com/cilium/proxy/actions/runs/8179371187/job/22365308893 Signed-off-by: Tam Mach <tam.mach@cilium.io> | 08 March 2024, 01:19:10 UTC |
| e373380 | Tam Mach | 05 March 2024, 14:43:34 UTC | patches: Call upstream callbacks via UpstreamFilterManager Envoy has moved the encodeHeaders() call to a new call path in upstream decoder filter. Move the upstream callbacks iteration call there to be just before the encodeHeaders() call, and call the iteration via UpstreamFilterManager so that the callbacks registered in the downstream filter manager are used. Call sendLocalReply also via the UpstreamFilterManager to have its local state updated properly for upstream processing. One more note comparing to the patches for 1.27+, the encodingHeader() call is still available in onPoolReady(), so we should move our patch on calling iterateUpstreamCallbacks() after. Relates: https://github.com/envoyproxy/envoy/pull/26916/files#r1176556258 Related commit: https://github.com/cilium/proxy/commit/860c2219c1d3a0e531c36bd2171d0b1678bba530 Related build: https://github.com/cilium/proxy/actions/runs/8156758309/job/22298887449 Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> | 07 March 2024, 13:15:44 UTC |
| c743b68 | Julian Wiedmann | 11 December 2023, 07:58:44 UTC | proxy: also install from-ingress-proxy rules with per-EP routing This is a v1.13-only patch, the closest upstream equivalent is 217ae4f ("Re-introduce 2005 route table"). It slightly differs from the v1.14 variant 579d0a4ff7f5 ("proxy: also install from-ingress-proxy rules with per-EP routing"), as for v1.13 we had only merged 4c441ab536a1 ("datapath: remove 2005 route table for ipv4 only"). Thus IPv6 is still using the 2005 rule, and we want to preserve existing behaviour as much as possible. In a config with per-EP routes, we therefore only install the 2005 rule for IPv6 when IPsec strictly requires it. Egressing traffic would usually get routed straight to eth0. Install the 2005 rule to divert the traffic into cilium_host first. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 840cdf1 | Gray Liang | 27 October 2023, 08:57:24 UTC | bpf: host: also handle from-egress proxy traffic [ upstream commit e96e9cd7542063ac6314f76c492e5b1ef41ee639 ] The from-host path already knows how to handle traffic that comes from the ingress proxy. Extend this logic to also cover traffic that originates from the egress proxy. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 8bcd7ca | Gray Liang | 27 October 2023, 09:46:19 UTC | datapath: disable net.ipv4.ip_early_demux for IPsec + L7 proxy [ upstream commit 5201896e0a393ec4199cf9b5be4ebac6374be12a ] [ backporter's notes: this is a backport to pre-cell iptables ] After forward traffic for an egress proxy onnection has traversed through cilium_host / cilium_net, we expect IPsec-marked packets to get handled by xfrm. This currently conflicts with early demux, which matches the connection's transparent socket and assigns it to the packet: ``` // https://elixir.bootlin.com/linux/v6.2/source/net/ipv4/tcp_ipv4.c#L1770 int tcp_v4_early_demux(struct sk_buff *skb) { ... sk = __inet_lookup_established(net, net->ipv4.tcp_death_row.hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif, inet_sdif(skb)); if (sk) { skb->sk = sk; ... } ``` It then gets dropped in ip_forward(), before reaching xfrm: ``` // https://elixir.bootlin.com/linux/v6.2/source/net/ipv4/ip_forward.c#L100 int ip_forward(struct sk_buff *skb) { ... if (unlikely(skb->sk)) goto drop; ... } ``` To avoid this we disable early-demux in a L7 + IPsec config. Note that the L7 proxy feature needs to deal with similar troubles, as the comment for inboundProxyRedirectRule() describes. Ideally we would build a similar solution for IPsec, diverting traffic with policy routing so that it doesn't get intercepted by early-demux. Signed-off-by: Zhichuan Liang<gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 298fa33 | Gray Liang | 27 October 2023, 09:22:10 UTC | iptables: preserve encrypt mark for egress proxy forward traffic [ upstream commit f018b20e9ef6c28bc37a94112b53ed9ad6890534 ] Once forward traffic for an egress proxy connection has traversed through cilium_host / cilium_net, we expect IPsec-marked packets to get handled by xfrm. But this currently conflicts with an iptables rule for the proxy's transparent socket, which then over-writes the mark: -A CILIUM_PRE_mangle -m socket --transparent -m comment --comment "cilium: any->pod redirect proxied traffic to host proxy" -j MARK --set-xmark 0x200/0xffffffff We can avoid this by adding an extra filter to this rule, so that it doesn't match IPsec-marked packets. Signed-off-by: Zhichuan Liang<gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| c22e2fb | Julian Wiedmann | 18 December 2023, 15:31:10 UTC | bpf: host: skip from-proxy handling in from-netdev [ upstream commit d4b81c03dbdb25f3f51d90149097669c31d0d59d ] from-proxy traffic gets redirected to cilium_host. Skip the proxy paths when handle_ipv*_cont() is included by from-netdev. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| e3c78d0 | Gray Liang | 11 December 2023, 08:38:53 UTC | iptables: filter table accepts from-proxy packets [ upstream commit 244a5e93f0be099a3c59ee8f87fdfd26849a6de7 ] GKE has DROP policy for filter table, so we have to explicitly accept proxy traffic. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 6ffa5da | Gray Liang | 04 December 2023, 11:35:16 UTC | proxy: opt-out from SNAT for L7 + Tunnel for some scenarios [ upstream commit 9fbd5a814b47131887661748996d876f541da3b8 ] Currently the L7 proxy performs SNAT for traffic when tunnel routing is enabled, even for cluster-internal traffic. This prevents cilium_host from detecting pod-level traffic, and we thus can't apply features. Modify SupportsOriginalSourceAddr(), so that the proxy doesn't SNAT such traffic when some conditions are met. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 519df25 | Julian Wiedmann | 10 December 2023, 13:57:22 UTC | pkg: proxy: only install from-proxy rules/routes for native routing [ upstream commit 0ebe5162373c00f85e7ae43d0bc5d474fa08c485 ] [ backporter's notes: this is a custom backport to init.sh. Only apply the change to IPv4 rules. ] With tunnel routing, traffic to remote pods already flows via cilium_host. This is sufficient for what IPsec requires. Thus currently only native routing requires the custom redirect logic for from-ingress proxy traffic. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| e2c757a | Julian Wiedmann | 08 December 2023, 08:11:01 UTC | bpf: l3: restore MARK_MAGIC_PROXY_INGRESS for from-proxy traffic [ upstream commit d2f1ea09b48416805600c8524443468ea4ffdaaf ] With https://github.com/cilium/cilium/pull/29530 in place, we now also divert proxy traffic to cilium_host when per-EP routes are enabled. But we potentially still need to deliver this traffic to a local endpoint - say for a pod-to-pod connection on the same node, with L7 proxy inbetween. In a configuration with per-EP routes but no BPF Host-Routing, l3_local_delivery() transfers the source identity to the skb->mark and redirects to bpf_lxc, where the to-container program handles the packet. If we transfer the packet with MARK_MAGIC_IDENTITY, to-container will look up the network policy and redirect to the L7 proxy *again*. Thus we need to fully restore the proxy's actual mark, so that to-container's inherit_identity_from_host() call finds the expected magic ID. It then sets the TC_INDEX_F_FROM_INGRESS_PROXY flag, and skips the redirect to L7 proxy. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 9141129 | Gray Liang | 23 October 2023, 03:13:25 UTC | bpf: work around scrubbing of skb->mark during veth transition [ upstream commit 3a93b00269b1fb762b2c9f98ab67a6ed3a333dda ] Previously we set skb->mark in from_host@cilium_host, expect the mark to remain unchanged after kernel transmits skb from cilium_host to cilium_net. The skb->mark is for instance used to transport IPsec-related information. However, as of 2023-10-19, kernel 5.10 still misses the backport patch[1] to fix a bug in skb_scrub_packet() which clears skb->mark for veth_xmit even if the veth pair is under the same netns: https://elixir.bootlin.com/linux/v5.10.198/source/include/linux/netdevice.h#L3975 To avoid hitting this issue, this patch sets metadata in skb->cb to survive skb_scrub_packet(), then to_host@cilium_net can retrieve this info and set proper mark. Only from_host bpf is setting cb, while from_lxc bpf is still using mark. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff70202b2d1a ("dev_forward_skb: do not scrub skb mark within the same name space") Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 224a481 | Gray Liang | 20 October 2023, 16:00:40 UTC | bpf_host can handle packets passed from L7 proxy [ upstream commit e78ff1690e4ab862057a6aefe5f0729340694254 ] Previously https://github.com/cilium/cilium/pull/25440 removed bpf_host's logic for host-to-remote-pod packets. However, we recently realized such host-to-remote-pod traffic can also be pod-to-pod traffic passing through L7 proxy. This commit made bpf_host capable of handling these host-to-remote-pod packets as long as they are originated from L7 proxy. Fixes: cilium/cilium#25440 Suggested-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 86a2536 | Robin Gögge | 15 November 2023, 15:41:19 UTC | Re-introduce 2005 route table [ upstream commit 217ae4f64183ce5112633338c88af2f16dfa8a14 ] [ backporter's notes: this is a custom backport to init.sh ] This commit re-introduced the 2005 routes that were removed by https://github.com/cilium/cilium/commit/9dd6cfcdf4406938c35c6ce2e8cc38fb5f2e9ea8 (datapath: remove 2005 route table for ipv6 only) and https://github.com/cilium/cilium/commit/c1a0dba3c0c79dc773ed9a9f75d5aa87b30f44f0 (datapath: remove 2005 route table for ipv4 only). Signed-off-by: Robin Gögge <r.goegge@gmail.com> Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| d46edac | Gray Liang | 20 October 2023, 07:57:02 UTC | Allow proxy replies to WORLD_ID [ upstream commit ac6385637a7bc39ec636e3808d3a5e9c13cb3c0e ] This is an alternative approach to fix cilium/cilium#21954, so that we can re-introduce the 2005 from-proxy routing rule in following patches to fix L7 proxy issues. This commit simply allows packets to WORLD as long as they are from ingress proxy. This was one of the solution suggested by Martynas, as recorded in commit message cilium/cilium@c534bb7: One fix was to extend the troublesome check https://github.com/cilium/cilium/blob/v1.12.3/bpf/bpf_host.c#L626 by allowing proxy replies to `WORLD_ID`. To tell if an skb is originated from ingress proxy, the commit extends the semantic of existing flags `TC_INDEX_F_SKIP_{INGRESS,EGRESS}_PROXY`, renames flags to clarify the changed meaning. Fixes: cilium/cilium#21954 (Reply from pod to outside is dropped when L7 ingress policy is used) Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 13f2d90 | Julian Wiedmann | 17 February 2023, 14:00:34 UTC | bpf: remove redundant IPcache lookup in from-host path [ upstream commit 99786beebba63e5e3c01533db027c8e17b820da4 ] [ backporter's notes: needed to resolve complexity issues in subsequent patches ] We first look up the destination endpoint to check for tunnel redirection, and then look it up a second time to access its sec_label and IPSec key. Make the first look-up unconditional, so that we can remove the second. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> | 07 March 2024, 12:36:18 UTC |
| 64b9041 | Cilium Imagebot | 06 March 2024, 09:47:24 UTC | images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> | 07 March 2024, 11:18:44 UTC |
| 6eaf493 | renovate[bot] | 06 March 2024, 09:39:51 UTC | chore(deps): update go to v1.21.8 Signed-off-by: renovate[bot] <bot@renovateapp.com> | 07 March 2024, 11:18:44 UTC |
| 9235263 | renovate[bot] | 04 March 2024, 20:18:26 UTC | chore(deps): update stable lvh-images Signed-off-by: renovate[bot] <bot@renovateapp.com> | 07 March 2024, 11:18:10 UTC |
| 1b06a5c | renovate[bot] | 04 March 2024, 20:14:14 UTC | chore(deps): update kindest/node docker tag to v1.27.11 Signed-off-by: renovate[bot] <bot@renovateapp.com> | 05 March 2024, 21:05:29 UTC |
| 8fdd9d4 | renovate[bot] | 04 March 2024, 04:15:37 UTC | chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> | 05 March 2024, 17:21:07 UTC |
| 1a6200e | Quentin Monnet | 30 January 2024, 16:18:58 UTC | ci/ipsec: Fix downgrade version retrieval [ upstream commit 6fee46f9e7531fd29ed290d5d4024dd951635e88 ] [ backporter's note: - test-e2e-upgrade doesn't exit on this branch. Remove it. - Minor conflict in tests-clustermesh-upgrade.yaml ++<<<<<<< HEAD + if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then + SHA="${{ inputs.SHA }}" + else + SHA="${{ github.sha }}" + fi ++======= + CILIUM_DOWNGRADE_VERSION=$(contrib/scripts/print-downgrade-version.sh stable) + echo "downgrade_version=${CILIUM_DOWNGRADE_VERSION}" >> $GITHUB_OUTPUT ++>>>>>>> 20a5826c31 (ci/ipsec: Fix downgrade version retrieval) ] Figuring out the right "previous patch release version number" to downgrade to in print-downgrade-version.sh turns out to be more complex than expected [0][1][2][3]. This commit is an attempt to 1) fix issues with the current script and 2) overall make the script clearer, so we can avoid repeating these mistakes. As for the fixes, there are two things that are not correct with the current version. First, we're trying to validate the existence of the tag to downgrade to, in case the script runs on top of a release preparation commit for which file VERSION has been updated to a value that does not yet contains a corresponding tag. This part of the script is actually OK, but not the way we call it in the IPsec workflow: we use "fetch-tags: true" but "fetch-depth: 0" (the default), and the two are not compatible, a shallow clone results in no tags being fetched. To address this, we retrieve the tag differently: instead of relying on "fetch-tags" from the workflow, we call "git fetch" from the script itself, provided the preconditions are met (we only run it from a Git repository, if the "origin" remote is defined). If the tag exists, either locally or remotely, then we can use it. Otherwise, the script considers that it runs from a release preparation Pull Request, and decrements the patch release number. The second issue is that we would return no value from the script if the patch release is zero. This is to avoid any attempt to find a previous patch release when working on a development branch. However, this logics is incorrect (it comes from a previous version of the script where we would always decrement the patch number). After the first release of a new minor version, it's fine to have a patch number at 0. What we should check instead is whether the version ends with "-dev". This commit brings additional changes for clarity: more comments, and a better separation between the "get latest patch release" and "get previous stable branch" cases, moving the relevant code to independent functions, plus better argument handling. We also edit the IPsec workflow to add some logs about the version retrieved. The logs should also display the script's error messages, if any, that are printed to stderr. Sample output from the script: VERSION Tag exists Prevous minor Previous patch release 1.14.3 Y v1.13 v1.14.3 1.14.1 Y v1.13 v1.14.1 1.14.0 Y v1.13 v1.14.0 1.14.1-dev N v1.13 <error> 1.15.0-dev N v1.14 <error> 1.13.90 N v1.12 v1.13.89 <- decremented 2.0.0 N <error> <error> 2.0.1 N <error> v2.0.0 <- decremented 2.1.1 N v2.0 v2.1.0 <- decremented [0] 56dfec2f1ac5 ("contrib/scripts: Support patch releases in print-downgrade-version.sh") [1] 4d7902f54a74 ("contrib/scripts: Remove special handling for patch release number 90") [2] 5581963cbf94 ("ci/ipsec: Fix version retrieval for downgrades to closest patch release") [3] 3803f539a740 ("ci/ipsec: Fix downgrade version for release preparation commits") Fixes: 3803f539a740 ("ci/ipsec: Fix downgrade version for release preparation commits") Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> | 01 March 2024, 07:42:08 UTC |
| 7bdb565 | Cilium Imagebot | 26 February 2024, 17:28:57 UTC | images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> | 27 February 2024, 10:57:58 UTC |
| d1f1f8f | renovate[bot] | 26 February 2024, 16:53:03 UTC | chore(deps): update go to v1.21.7 Signed-off-by: renovate[bot] <bot@renovateapp.com> | 27 February 2024, 10:57:58 UTC |
| 7ff0fe4 | renovate[bot] | 26 February 2024, 16:35:08 UTC | chore(deps): update quay.io/lvh-images/kind docker tag to v6.6-20240221.111541 Signed-off-by: renovate[bot] <bot@renovateapp.com> | 27 February 2024, 09:57:51 UTC |
| 03c9bce | Cilium Imagebot | 26 February 2024, 08:48:04 UTC | images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> | 26 February 2024, 15:28:02 UTC |
| 71e9e31 | renovate[bot] | 26 February 2024, 08:35:28 UTC | chore(deps): update all-dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> | 26 February 2024, 15:28:02 UTC |
| 32245ff | renovate[bot] | 26 February 2024, 08:35:57 UTC | chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> | 26 February 2024, 14:34:07 UTC |
| 581e3d8 | Birol Bilgin | 15 February 2024, 06:55:29 UTC | ci: Restrict running tests to only the organization-members team [ upstream commit b19321e0274cc168295e0c270275f0f835bbe2ae ] This commit updates the Ariane configuration to include the GitHub organization team 'organization-members' in the list of allowed teams. Consequently, only members of this specific team will have the authorization to initiate test runs via issue comments. Signed-off-by: Birol Bilgin <birol@cilium.io> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> | 20 February 2024, 16:31:43 UTC |
