Allow connect to use configured TLS keys #2532
Conversation
|
Weelll ... there was a reason why I did use the key IDs to reference the keys. If you specify the key on the commandline it will be present in the commandline args for that process for everyone to see (just do a 'cat /proc//cmdline and you can read the entire commandline argument details), with not even basic security restrictions. |
|
Which incidentally was the reasons why I want to rework DH-CHAP key handling to use the key store. |
|
Yep, I thought the same. Thus I am not sure if we really want this and I got here due the work on linux-nvme/libnvme#890 where @martin-gpy ask for the JSON output generated by the 'connect' command is showing the 'configured key'. The key in the keystore is obviously not the 'configured key' thus we can't produce a 'correct' JSON configuration file. I think we should keep the discussion in place, thus let's have it here linux-nvme/libnvme#890 |
|
And there is also |
|
We could insert the key description in the json output. With that we can lookup the matching key upon reload. |
igaw
force-pushed
the
tls-keys
branch
6 times, most recently
from
26c0fdc to
b9c74e0
Compare
|
During some more testing of various use cases, I found some more issues. The last patch adds a new feature which allows to export a generated key to a keyfile. This should help the use case to maintain a |
igaw
force-pushed
the
tls-keys
branch
4 times, most recently
from
6b9f5c0 to
917f4fa
Compare
Fetch TLS API changes. Signed-off-by: Daniel Wagner <[email protected]>
The spec is limiting the size of both variables to one byte, thus there is no need to use wider types. Signed-off-by: Daniel Wagner <[email protected]>
The connect-all command accepts JSON configuration but not the connect command. connect-all will try to connect to all possible resources, which includes creating discovery controllers. This might not always needed or wanted. The connect command will only connect to the controllers listed in the configuration file and doesn't to any additional discovery at all. Signed-off-by: Daniel Wagner <[email protected]>
Extend the connect command also to accept the pre-shared key via command line. Obviously, this is not recommended to use for a production system but for testing this is a simple way to get a setup working. Signed-off-by: Daniel Wagner <[email protected]>
With the added support to also accept the key via the command line update the documentation accordingly. Signed-off-by: Daniel Wagner <[email protected]>
Load keys to the keyring when the nvme-tcp module is loaded. Signed-off-by: Daniel Wagner <[email protected]>
Export the keys with the correct encoding scheme. Signed-off-by: Daniel Wagner <[email protected]>
Since this file contains secret enforce the read/write permission limited to the owner only. Signed-off-by: Daniel Wagner <[email protected]>
Use the variable name consistently. The rest of the code base names this variable as version. Signed-off-by: Daniel Wagner <[email protected]>
When creating a new key and it is inserted into keystore also support to append it to a keyfile. Signed-off-by: Daniel Wagner <[email protected]>
Add the newly added --keyfile command line option. Signed-off-by: Daniel Wagner <[email protected]>
Extend the
--tls_keyand--keyringargument to accept also configured keys.Depends on linux-nvme/libnvme#894