SROS 2 first setup: keystore, enclaves and the three variables

To secure a ROS 2 system with SROS 2 you create a keystore, create an enclave for each node you want to protect, then point your shell at the keystore and turn security on with three environment variables. The commands below come from the SROS2 Linux guide.

Create the keystore and enclaves

The keystore is a directory that holds the certificate authority material and the per node keys. An enclave is a named set of security artifacts, usually one per node or process. The guide uses a talker and listener demo:

ros2 security create_keystore demo_keystore
ros2 security create_enclave demo_keystore /talker_listener/talker
ros2 security create_enclave demo_keystore /talker_listener/listener

The enclave name is a path. Pick a naming scheme early, for example one prefix per robot, because renaming later means regenerating keys.

Turn security on

The same guide sets three variables in the shell that launches the node:

export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce

What each does:

• ROS_SECURITY_KEYSTORE points at the keystore directory.
• ROS_SECURITY_ENABLE switches the security features on. Without it, nothing above applies.
• ROS_SECURITY_STRATEGY set to Enforce is the value the guide uses. This post does not cover the other value, so read the current SROS 2 documentation for its exact behavior before you rely on it.

Then start each node with its enclave. In the demo, that means telling the node which enclave to use at launch.

Common ways this goes wrong

• Setting the variables in one terminal and launching nodes from another. Each process reads its own environment.
• A node that cannot find its enclave. Check that the enclave path matches what you created.
• Mixing secured and unsecured nodes in the same domain and wondering why they do not see each other. That is the intended result.
• Copying a keystore with private keys into a container image. Mount it at run time instead, and keep it out of version control.

Treat the keystore like a secret store

The keystore contains private keys. Limit who can read it, back it up on purpose and plan for rotation. If you ship robots to customers, decide up front whether each robot gets its own certificate authority or shares one, because that choice sets how much one stolen key can do.

A sensible order of work

Do the demo first, exactly as written, on one machine. Then repeat it across two machines so you see authentication work over a real network. Only then apply it to your own nodes. Keep a short runbook with the commands you used, the enclave names and the place the keystore is stored, so the next engineer can add a node without guessing. Add a test to your build that launches the system with security enabled, so a permissions mistake is caught before it reaches a robot.

Quick check

Sources

• SROS2 Linux setup guide
• SROS2 repository
• ROS 2 DDS-Security integration (design document)

Last reviewed: 19 October 2026.