aimxhaisse
commented
3 weeks ago IMHO this could be tackled outside of the Rust code, in a set of guidelines or documentations for different setups (docker provides it, k8s provides it, standard linux distributions as well via ufw or similar:
-
With k8s where doing it in Rust wouldn't play well: in most setups IP addresses are dynamic (to allow for automatic rebalancing/recovery if a machine crashes for instance) ; instead, k8s provides ways via network policies to define who can access what, it's not via IP,
-
Operators relying on UFW or iptables want to manage everything in a unified way, and not have to fiddle with internals/specificities of each services in their stack ; just for Eth they likely already have rules for validator, beacon, exec nodes, web3signer etc, maybe ingresses in the middle, if one component of this stack has a specific way of doing it, it will go in their way and actually make it more error-prone,
-
For solo stakers, most guides around explain how to configure the firewall via UFW or other flavors of it so they are used to secure validator clients. Same here, it's hard to capture what's done if half of it is done one way for the validator client and the other half for commit boost differently.
If guidelines are well written and explained, it's even better as it can harden the security of other components in the stack (i.e: someone who wants to commit-boost following a guide, might realize their existing validator client could be hardened in the same way).
Another point on security: if it's done via Rust and needs to play with iptables or similar, it will need root access to do so, then you have a component in your stack that needs high-privileges, and it's a no-go if say, it has to run on the same machine as validators.
To enhance security, restrict network access to trusted IPs or networks only. This reduces the risk of unauthorized access and protects sensitive data by limiting interactions to specific, authorized entities.