connectivity: Extend encryption interface derivation for managed K8s #37675
Labels
area/CI
Continuous Integration testing issue or flake
area/encryption
Impacts encryption support such as IPSec, WireGuard, or kTLS.
cilium-cli
This PR contains changes related with cilium-cli
integration/cloud
Related to integration with cloud environments such as AKS, EKS, GKE, etc.
Comments
|
This issue has been automatically marked as stale because it has not |
github-actions
bot
added
the
stale
brb
removed
the
stale
|
This issue has been automatically marked as stale because it has not |
github-actions
bot
added
the
stale
brb
removed
the
stale
|
This issue has been automatically marked as stale because it has not |
github-actions
bot
added
the
stale
|
This issue has not seen any activity since it was marked stale. |
julianwiedmann
added
cilium-cli
smagnani96
added a commit
that referenced
this issue
Feb 17, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for retrieving the egress device from client-server pods and vice-versa. Before the patch, we solely rely on `ip route get dstIP`, using the returned device as egress. However, we noticed that in aws-cni chaining mode, such returned device is not actually used. Instead, looking at the routing tables in the server node, we found that there's a specific table with a route that uses a different egress device for that particular IP. The related issue in our previous tests is #37675. We now fix this for pod-to-pod-encryption-v2, but we might want to adopt the same logic for v1. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 17, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for retrieving the egress device from client-server pods and vice-versa. Before the patch, we solely rely on `ip route get dstIP`, using the returned device as egress. However, we noticed that in aws-cni chaining mode, such returned device is not actually used. Instead, looking at the routing tables in the server node, we found that there's a specific table with a route that uses a different egress device for that particular IP. The related issue in our previous tests is #37675. We now fix this for pod-to-pod-encryption-v2, but we might want to adopt the same logic for v1. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 18, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for retrieving the egress device from client-server pods and vice-versa. Before the patch, we solely rely on `ip route get dstIP`, using the returned device as egress. However, we noticed that in aws-cni chaining mode, such returned device is not actually used. Instead, looking at the routing tables in the server node, we found that there's a specific table with a route that uses a different egress device for that particular IP. The related issue in our previous tests is #37675. We now fix this for pod-to-pod-encryption-v2, but we might want to adopt the same logic for v1. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 18, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for retrieving the egress device from client-server pods and vice-versa. Before the patch, we solely rely on `ip route get dstIP`, using the returned device as egress. However, we noticed that in aws-cni chaining mode, such returned device is not actually used. Instead, looking at the routing tables in the server node, we found that there's a specific table with a route that uses a different egress device for that particular IP. The related issue in our previous tests is #37675. We now fix this for pod-to-pod-encryption-v2, but we might want to adopt the same logic for v1. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 18, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for retrieving the egress device from client-server pods and vice-versa. Before the patch, we solely rely on `ip route get dstIP`, using the returned device as egress. However, we noticed that in aws-cni chaining mode, such returned device is not actually used. Instead, looking at the routing tables in the server node, we found that there's a specific table with a route that uses a different egress device for that particular IP. The related issue in our previous tests is #37675. We now fix this for pod-to-pod-encryption-v2, but we might want to adopt the same logic for v1. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 19, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for
retrieving the egress device from client-server pods and vice-versa.
Before the patch, we solely rely on `ip route get dstIP`, using the
returned device as egress. However, we noticed that in aws-cni chaining
mode, such returned device is not actually used. Instead, looking at the
routing tables in the server node, we found that there's a specific table
with a route that uses a different egress device for that particular IP.
Therefore, the final command to be issued should be:
`ip route get {dstIP} from {srcIP} iif cilium_host`.
The interface specified does not matter since, if present, the route
matching srcIP is not making use of the interface field to match.
The related issue in our previous tests is #37675.
We now fix this for pod-to-pod-encryption-v2, but we might want to adopt
the same logic for v1.
Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this issue
Feb 19, 2025
This commit adjusts the current logic in `pod-to-pod-encryption-v2` for
retrieving the egress device from client-server pods and vice-versa.
Before the patch, we solely rely on `ip route get dstIP`, using the
returned device as egress. However, we noticed that in aws-cni chaining
mode, such returned device is not actually used. Instead, looking at the
routing tables in the server node, we found that there's a specific table
with a route that uses a different egress device for that particular IP.
Therefore, the final command to be issued should be:
`ip route get {dstIP} from {srcIP} iif cilium_host`.
The interface specified does not matter since, if present, the route
matching srcIP is not making use of the interface field to match.
The related issue in our previous tests is #37675.
We now fix this for pod-to-pod-encryption-v2, but we might want to adopt
the same logic for v1.
Signed-off-by: Simone Magnani <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the encryption test does
ip route get $REMOTE_POD_IPto derive an interface which is used to send a request to that pod. However, this might not work on managed K8s (e.g., EKS) in which there might be multiple ifaces depending on a source IP addr (cilium/cilium-cli#1304 (comment)).The text was updated successfully, but these errors were encountered: