NodeMapV2: Introduce a V2 of the NodeMap which includes SPI values #31431
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maintainer-s-little-helper
bot
added
the
dont-merge/needs-release-note-label
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
2 times, most recently
from
7da59a0
to
13ef906
Compare
pchaigno
added
the
release-note/misc
maintainer-s-little-helper
bot
removed
the
dont-merge/needs-release-note-label
pchaigno
added
dont-merge/needs-release-note-label
maintainer-s-little-helper
bot
removed
dont-merge/needs-release-note-label
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
from
13ef906
to
761f226
Compare
dylandreimerink
approved these changes
Mar 25, 2024
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
8 times, most recently
from
f80d978
to
1493c34
Compare
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
from
8d69eeb
to
2134502
Compare
This commit introduces a V2 of the NodeMap. This V2 map grows a "SPI" field of size u8. This will allow each node within the node map to also be associated with an IPSec SPI. For at least two release cycles we will maintain the V1 map and mirror writes from V2 into V1 map. This allows a user to 'downgrade' mid-patch release without needing a migration. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
This commits introduces a V2 of the NODE_MAP eBPF map which now associates an IPSec SPI with each node. The SPI associated with the IPSec of a remote node can now be retrieved by querying the NODE_MAP_V2 eBPF map. All eBPF unit tests are updated accordingly. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
from
2134502
to
a3da47f
Compare
|
Latest push now performs "mirroring" of MapV2 Update and Delete. Tests are updated to ensure we
I think the initial reviews from others can still stand, these new updates are solely focusing on new eBPF map manipulation. |
|
Hi @ldelossa 👋 Is this binary file pushed by mistake ? |
|
@harsimran-pabla Nope, see: |
I should have read the comments :) |
asauber
reviewed
Mar 29, 2024
pchaigno
added
needs-backport/1.15
pchaigno
approved these changes
Apr 3, 2024
|
@ldelossa I've labeled the PR according to our Slack discussion. |
|
After some further conversation with community team, we wont be back porting this into v1.15. |
ldelossa
removed
the
needs-backport/1.15
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
2 times, most recently
from
7e0a51d
to
c42eff2
Compare
|
/test |
This commit updates all references of NodeMap to NodeMapV2. The restoration of the NodeMapV2 is updated to take account of nodemap.NodeValueV2. The NodeMapV2 is now loaded with SPI values on (initial) NodeUpdates, supplying the SPI to the datapath. Tests are updated as well. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
This commit adds a migration when the v1 NodeMap is detected. The migration first opens the ENCRYPT_MAP to obtain the local SPI. This SPI will be the same for all nodes as long as a key rotation is not occurring during an upgrade. Which should never occur. The values from the V1 map is then migrated to the V2 map and the SPI retrieved from the ENCRYPT_MAP is applied to all migrated values. The migrated map is then unpinned from bpffs after a successful migration. This migration is kicked off within the NodeMap's Cell onStart hook which should ensure it runs before the map is utilized by other Cilium components. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
This commits updates the cilium-dbg command to list the SPI value of NodeMapV2's entries. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
ldelossa
force-pushed
the
ldelossa/node-map-spi-oss
branch
from
c42eff2
to
88316a6
Compare
|
/test |
Comment on lines
+195
to
+199
| struct node_value { | ||
| __u16 id; | ||
| __u8 spi; | ||
| __u8 pad; | ||
| }; |
There was a problem hiding this comment.
Could you please also add this to the alignchecker? 🙏
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds a new V2 addition to the NodeMap.
The NodeMap is responsible for inventorying and restoration of allocated NodeIDs which are subsequently used to correctly match XFRM policies and states given the ultimate destination of IPSec encrypted traffic.
The v2 edition of NodeMap now associates each node entry with their SPI which is also used to correctly match XFRM policies and states given the ultimate destination of IPSec encrypted traffic.
However, by providing the SPI in NodeMap we can now query the SPI value associated with a Cilium managed node. Prior to this we could only query SPI on a per-pod basis.
This ability becomes especially useful when combined with the Encrypted Overlay feature, and provides us a way to retrieve SPI when only the destination Node address is obtainable, as opposed to the destination pod's address.
This PR includes an upgrade migration which will copy v1 map entries into the v2 map and fill in the current SPI.
This migration works on the assumption that the cluster has a stable SPI and no pending key rotation is occurring during the migration (Cilium upgrade in other words).
It is best to review this PR one commit at a time.