Page MenuHomePhabricator

Allow SSH keys (and other Conduit tokens) to be restricted to specific IP ranges
Open, LowPublic

Description

In some cases, including cases in the Phacility cluster, we can meaningfully reduce the cost of private key disclosure by restricting keys and tokens to work only from specific source subnets.

For example, the signing key for intra-cluster requests as a cluster agent can be locked to the cluster subnet. An attacker would then need to both learn the private key and gain access to a host (which is generally a strictly higher barrier, as hosts necessarily have access to the key).

This isn't especially important, as it only serves to harden the cluster, but is probably also not very difficult.

This would look something like an option to restrict an SSH key to specific subnets (like 172.30.0.0/24) and then checks in Conduit request authentication and the SSH daemons that the request originates from an allowed IP in the range.

This can apply to Conduit tokens in the general case after T5955.

Event Timeline

epriestley raised the priority of this task from to Low.
epriestley updated the task description. (Show Details)
epriestley added projects: Security, Phacility.
epriestley moved this task from Backlog to Do After Launch on the Phacility board.
epriestley added a subscriber: epriestley.

The cluster tokens (introduced in D10990; for context, see T5955 / T2783) should probably also be lockable to a defined range.

It may make sense to define some global cluster IP range, and then filter cluster tokens and trusted SSH keys to that range, regardless of any other restrictions applied (i.e., they must pass both cluster filtering and explicit filtering).