This is another in the small series of ‘things that have changed in Selenium Grid but I have not yet added to the official docs’ posts.

When Selenium Grid was first created, the expectation was that your Grid Hub was nicely secured inside your network, along with your Nodes so everything should be trusted to communicate. But now that we live in a cloud environment, that assumption isn’t quite as tight as it once was. You could have everything tightly locked down in your AWS account, but if someone gets their access key comprimised who can make instances, well, it’s a problem. I know if I was a bad guy, I would be scanning for open Grid Hubs and then figure out how to register with them. There is a wealth of information to be had; competitive intelligence on new features not available in the wild, account details for production testing, etc.

Last night I pushed a change that prevents rouge Grid Nodes from registering in your Grid Hub (so it will be available in the next alpha or you can build it yourself now). I don’t know if this has ever happened in the wild, but the fact that it could is enough that it needed to be closed down.

In order to secure Node registration, you need to supply the new argument --registration-secret in a couple different places. If the secrets do not match, the Node is not registered. This secret should be treated like any other password in your infrastructure, which is to say, not checked into a repo or other practice. Instead it should be kept in something like Hashicorp Vault or AWS Secrets Manager and only accessed (via automated means) when needed.

Standalone Server

When running your Hub as a single instance, there is only one process so only one place that needs the secret handed to it

<pre class="wp-block-code">```
  java -jar selenium.jar \
       hub \
       --https-private-key /path/to/key.pkcs8 \
       --https-certificate /path/to/cert.pem \
       --registration-secret cheese


*Distributed Server*

When running your Hub in a distributed configuration, the Distributor and Router servers need to have it.


```
  java -jar selenium.jar \
       distributor \
       --https-private-key /path/to/key.pkcs8 \
       --https-certificate /path/to/cert.pem \
       -s https://sessions.grid.com:5556 \
       --registration-secret cheese \
```
```

```

```
  java -jar selenium.jar \
       router \
       --https-private-key /path/to/key.pkcs8 \
       --https-certificate /path/to/cert.pem \
       -s https://sessions.grid.com:5556 \
       -d https://distributor.grid.com:5553 \
       --registration-secret cheese
```
```

*Node*

Regardless of your approach to running the Server, the Node needs it too. (Obviously.)

```

```
  java -jar selenium.jar \
       node \
       --https-private-key /path/to/key.pkcs8 \
       --https-certificate /path/to/cert.pem \
       --detect-drivers \
       --registration-secret cheese
```
```

*Detection*

When a Node fails to register, two things happen;

1. A log entry is created at an ERROR level saying a Node did not register correctly. Your Selenium infrastructure needs the same attention to its logging as your production infrastructure. So this should trip an alert to someone in whatever manner it is this would happen for a potential security problem in any other environment.
2. An event is dropped onto the bus. The Selenium Server shipped with a 0mq bus built-in, but when deploying in a real environment I would suggest using it with something like AWS SQS (or your cloud’s equivilant) as your queuing system which you and then have something like AWS Lambda watch for these events and trigger actions accordingly.

It should be noted further that these are all on the side of the Server, not the Node. The rouge Node is not given any indication that secrets are configured or that the secret they sent was incorrect.