Hello,
The https://learn.hashicorp.com/tutorials/nomad/security-gossip-encryption?in=nomad/transport-security doesn't clearly describe the possible consequences of compromising the encrypt key.
Since it's stored in plain text I wonder what is the risk.
And if there is any recommendation on how that part could be hardened besides read access to nomad config.
The gossip encryption key is _mostly_ a denial-of-service protection (it also prevents an information leak about server IDs, IP addresses and raft versions, but that's not part of the security model). If the gossip key is compromised, the attacker could use it to add or remove servers from the "member list" used for raft consensus. That could create a situation where legitimate servers don't think they have quorum during leadership elections and where they try to make RPC connections to a fake server.
Note that this isn't the same as compromising the data that's shared between servers. That data is sent over the RPC channel, which should be protected via mTLS and ACLs. So if the gossip key is compromised but mTLS is not, the fake servers will get rejected when trying to make RPC connections.
You might also want to read thru the Nomad Security Model documentation for more context.
And if there is any recommendation on how that part could be hardened besides read access to nomad config.
We have a guide on rotating the gossip key using Vault. This was written for Consul but everything here applies to Nomad as well.
Most helpful comment
The gossip encryption key is _mostly_ a denial-of-service protection (it also prevents an information leak about server IDs, IP addresses and raft versions, but that's not part of the security model). If the gossip key is compromised, the attacker could use it to add or remove servers from the "member list" used for raft consensus. That could create a situation where legitimate servers don't think they have quorum during leadership elections and where they try to make RPC connections to a fake server.
Note that this isn't the same as compromising the data that's shared between servers. That data is sent over the RPC channel, which should be protected via mTLS and ACLs. So if the gossip key is compromised but mTLS is not, the fake servers will get rejected when trying to make RPC connections.
You might also want to read thru the Nomad Security Model documentation for more context.
We have a guide on rotating the gossip key using Vault. This was written for Consul but everything here applies to Nomad as well.