Domain based whitelisting for outbound requests

Is there a recommended pattern for whitelisting outbound requests on a per job-group basis?

It is common practice for businesses to tightly control which applications are able to connect out to which external sites. In a traditional environment where you always know where an application is running this can be achieved with a forward proxy like squid and a set of acls specifying which destination domains various source IPs are allowed to reach. In a nomad cluster this is made more complicated since you don’t always know where your applications will be running or which IP they will have.

The possible solutions that occur to me are

  1. Restrict job-groups to only specific clients that have been assigned the required whitelists in squid. (This works but would require a huge number of clients to maintain redundancy and seems to defeat the purpose of nomad)
  2. Require that all applications making outbound requests through the proxy provide a client cert that the proxy can use to determine the its domain whitelist. (This works for home-grown applications that can be modified to pass a client cert, but isn’t always possible for other applications).
  3. Use an overlay network to split applications into consistent subnets that can be whitelisted as a block. (I’m not 100% sure this is possible without creating application-specific client groups similar to #1).
  4. Run squid as a system job and use ipvlan networking to assign each application type a specific internal subnet that can be used to determine whitelists. (This would work for the applications running in the nomad cluster but would mean that the nomad clients themselves have unrestricted access to the internet since they can’t whitelist themselves)
  5. Render the squid template dynamically based on consul services, connecting specific service names to the whitelists they require. (This ends up being a slightly more automatic version of #1, and would allow application A to use application B’s whitelists if they were on the same nomad client)

The only other solution I can think of is to somehow use Consul Connect in place of squid to restrict the domains the job-group is allowed to reach, but there doesn’t appear to be anything in the documentation about using it in this way, and even if I did come up with a way to do it through Consul Connect I suspect it would effectively break Consul Connect’s ability to control traffic between internal applications as it was originally intended.

Is there some established pattern I’m missing or is this still an unsolved problem for Nomad?

1 Like