Project

General

Profile

Actions

User story #6250

closed

Per-Host inventory upload keys / access restrictions

Added by Florian Heigl about 9 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
System integration
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

Currently I think it is easily possible for one host to inject / overwrite a different system's inventory data.
It should already be possible to set up different curl user accounts for different network segments, but that needs modification of the system techniques, which isn't fun either.

Goal would be for a host not to be able to send inventory for another host. Most importantly not for one attached to a different rudder relay / root, and ideally also not even for any other system.
The protection of root & relay against such misuse should probably also be checked, no idea if they accept inventory data for themselves over the "client" channel.

I'll not muse about ways to do it.

Note:
There's an obvious edge case with reinstall-with-different uuid; but that case already exists and already causes slight problems when it happens.
(uuid conflicts, name conflicts, both need to be considered and different things happen)


Related issues 1 (0 open1 closed)

Is duplicate of Rudder - Architecture #6356: Inventory endpoint should validate agent signatureReleasedFrançois ARMAND2015-04-16Actions
Actions #1

Updated by François ARMAND about 9 years ago

Thanks for that. Of course :)

What would be the correct secret for auth ? The cfengine key ? Something else ?

Of course, we will also need to manage the case for new inventory - so that we actually are able to display it in the UI :)

Actions #2

Updated by François ARMAND about 9 years ago

  • Category set to System integration
  • Target version set to 3.1.0~beta1
Actions #3

Updated by François ARMAND about 9 years ago

OK, so we have to consider at least the following cases to take into account in the prevention mechanism:

- UUID collision,
- reinstall with a different UUID,
- vm cloning.

The main solution whitch come to mind is it sign the inventory (we already have an asym key for the agent). So that when we accept a node, we both have the uuid for identification, and a mean to check the entity that generated the datas.
Of course, it doesn't help for vm cloning (because the clone has the same UUID and key, so signature will be ok).

For now, that seems to be the only way to go. Of course, we welcome any contribution to the discussion :)

Actions #4

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 3.1.0~beta1 to 3.1.0~rc1
Actions #5

Updated by Benoît PECCATTE almost 9 years ago

  • Is duplicate of Architecture #6356: Inventory endpoint should validate agent signature added
Actions #6

Updated by Benoît PECCATTE almost 9 years ago

  • Status changed from New to Rejected

Sorry I was not aware of this bug when I opened #6356
I'm rejecting this one as duplicated sine the other one is already solved.

Actions

Also available in: Atom PDF