fix: device.id is derived from device certificate if certificate exists#3372
Conversation
The phrasing sounds a little strange here. The precedence of source of the device.id value just follows the cli convention of: argument => env variable => configuration, where the first value present is used. |
Codecov ReportAttention: Patch coverage is Additional details and impacted files📢 Thoughts on this report? Let us know! |
Robot Results
|
Yeah I fixed the phrasing. Prioritizing the argument is what this PR fixed. Note that the order of env variable => configuration is the responsibility of the tedge config settings and should be this order for all configs. |
didier-wenzek
left a comment
There was a problem hiding this comment.
Okay we have now a more consistent behavior regarding device id / tedge config / tedge connect.
However, it would be good to add 4 independent tests matching exactly the 4 cases described by #3369. The current tests are useful but a bit complicated to follow because very dependent of the whole sequence of check vs tear-down steps.
| ${output}= Execute Command tedge config get c8y.device.id exp_exit_code=1 | ||
| ${output}= Execute Command tedge config get c8y.device.id --profile foo exp_exit_code=1 |
There was a problem hiding this comment.
I was expecting a cascading behavior here: i.e. if there is no specific device id for a cloud profile, then the general device id is used.
Is this because explicit paths have set for the misc cloud profiles?
I got it: this is because no device id has been set in the config file.
I would be good to have a more consistent cascading behavior.
There was a problem hiding this comment.
I would be good to have a more consistent cascading behavior.
If no specific device.cert_path is set for a cloud profile, the result here will be different.
# Remove specific paths
$ tedge config unset c8y.device.cert_path
$ tedge config unset c8y.device.cert_path --device foo
# create a new cert for the generic one
$ tedge config cert create --device-id input
# get device ids
$ tedge config get device.id
input
$ tedge config get c8y.device.id
input
$ tedge config get c8y.device.id --profile foo
inputThere was a problem hiding this comment.
This behaviour also caught me by surprise as setting a cloud profile certificate path changes the device.id value returned, even if the cloud profile certificate does not exist...though after reviewing it, it seems to make sense as the act of creating a different cert path for a cloud profile, will decouple it from the generic/default certificate...so it makes it easier for system users to control the device.id inheritance without forcing them to create the certificate.
Added a new suite ( |
didier-wenzek
left a comment
There was a problem hiding this comment.
Approved. Thanks for taking the time to make more consistent how the device id is used across the misc tedge cert / config and connect API.
| ### All cert/key paths are the default | ||
| ${output}= Execute Command tedge cert create --device-id input | ||
| Should Contain ${output} CN=input | ||
| Validate device IDs input input input | ||
| Execute Command tedge cert remove |
There was a problem hiding this comment.
This is the cascading behavior I was expecting.
reubenmiller
left a comment
There was a problem hiding this comment.
Approved (only 1 minor test case renaming required)
Overall it would benefit from splitting the "Device ID derivation" into individual test cases (and possibly moving it to a new Test Suite so it can use a single "Suite Setup" and reuse the same device for all test cases with suitable cleanup logic between tests)...however this is not a blocker for merging the PR.
a93847a to
88e81bc
Compare
tests/RobotFramework/tests/tedge/device_id/device_id_usecases.robot
Outdated
Show resolved
Hide resolved
tests/RobotFramework/tests/tedge/device_id/device_id_derivation.robot
Outdated
Show resolved
Hide resolved
* device.id always uses a value from device certificate. If no certificate exists, returns a value from tedge.toml file. Both don't exist, finally it returns an error. * tedge connect doesn't validate if device certficate's CN matches the value from tedge.toml file. It just consume the value from device.id. * The CN of `tedge cert create` is determined by this order: 1) the value of --device-id option 2) the value of tedge config get <device_id_key> Signed-off-by: Rina Fujino <rina.fujino.23@gmail.com>
88e81bc to
83a82b2
Compare
Proposed changes
device.idalways uses the value from a device certificate. If no certificate exists, it returns a value from thetedge.tomlfile. Both don't exist, finally it returns an error.tedge connectdoesn't validate if device certficate's CN matches the value from thetedge.tomlfile. It just consume the value fromdevice.id.tedge cert createcreates a cert, which CN is determined by this order. 1) the value given by the--device-idoption, 2) the value fromtedge config get <corresponding_device_id_key>Types of changes
Paste Link to the issue
#3369
Checklist
cargo fmtas mentioned in CODING_GUIDELINEScargo clippyas mentioned in CODING_GUIDELINESFurther comments