Hi all, my team at Amazon is looking for your input on security tools!
Summary
Developers looking to secure their robots and actively develop new nodes will have to manually create keys and policies, as well as debug their node connectivity should security not be set up properly. Conversion from an unsecure DDS to secure DDS may also have a performance impact, therefore developers will need to test and develop with security enabled for production.
SROS2 has done an excellent job creating their own wrappers to demonstrate the security capabilities of FastRTPS and RTI Connext. With this in mind, we want to bring forth three tools to make security quicker and less error prone for developers.
Manual Key Generation
Developers need to manually run generate keystore, then generate key for each of their nodes.
This is error prone for developers since we often use docker containers, different machines, direct development on the robot, and all the amazing ways we like to create robots.
Solution: cmake build macro
We would like to present a cmake macro for generating the key and keystores during build time. Our macro uses SROS2 on the back end, but the macro definition should stay the same should a team want to define their own security generator. This enables each developer to have the expected authentication without having extra steps at run time. The ROS security environmental variables will still need to be set outside the macro.
ros2_secure_node
# NODES (macro multi-arg) takes the node names for which keys will be generated
# SECURE (cmake arg) if not define or OFF, will not generate key/keystores
# SECURITY_DIR (cmake arg) if defined will be the location of the keystore (it will be created if it does not exist). A message will be generated to a default location should SECURITY_DIR not be defined
# SECURITY_KEYSTORE (cmake arg) if defined will be the name of the keystore (it will be generated if it does not exist)
# POLICY_DIR (cmake arg) if defined, will compile policies by node name into the access private certificates (e.g POLICY_DIR=/etc/policies, Generate: <node_name> /etc/policies/<node_name.yaml>)
ros2_secure_node(NODES node_name_1 node_name_2 ...)
Manual Policy Inspection and Generation
Access policy generation is manual.
A release engineer or developer would need to inspect the node graph, all services, and soon actions to create policies for each node. We are considering creating two tools for easing deployment to production security and debugging.
Solution: Node Graph Tools
- A node graph inspection tool will be available to take a snapshot of the node graph and generate policies for each node. It will print feedback on nodes which advertise services and actions, which developers will use to add permissions for client nodes.
- (OPTIONAL) rqt_graph modified with permissions, such that a developer can inspect their system and visualize the access control of their nodes.
Quality and Performance Test
Performance between DDS providers with security on and off
Developers will be using ROS2 for a myriad of applications, and teams will want to know the effects of choosing certain providers over others, and the level of security they need. ApexAI provides their repository (https://github.com/ApexAI/performance_test) which we will use to run a series of performance tests with and without security to prevent regression and understand system impact.
Will these tools help you?
What other requirements would be helpful for each of these tools?