HN Explorer

Ask HN: Should DEV and PROD environments be segmented?

3 points by jbpadgett ↗ HN
I am experiencing dissonance between developers, security, and infrastructure teams on the topic of whether to do network layer segmentation for DEV and PROD environments.

Security and Infra folks say yes and want firewalls between the environments with different levels of change control.

Developers say no and argue that different VMs/containers are sufficient and don't see value in having firewalls between DEV and PROD.

I see value on both sides of this argument but would love to know what others are doing here.

3 comments

[ 3.0 ms ] story [ 25.1 ms ] thread
deanfranks
As a developer it is worth it as long as you have separate teams responsible for development and production. Segmentation means that a prod server can't accidentally be configured to access a dev resource (db instance, etc). If you have development hand off installation packages and instructions it also means that dev never has to touch prod servers (except read access to logs, etc). It also eliminates the temptation to "temporarily" use a dev machine/instance as part of prod to solve a problem (and then leaving it that way for years).
jbpadgett
I have seen the following patterns implemented:

Pattern 1: * DEV VLANs + DEV Subnets * PROD VLANSs + PROD Subnets * Firewalls between DEV and PROD subnets at network layer - firewall rules implemented by separate net/sec team

Pattern 2: * DEV VLANs + DEV Subnets * PROD VLANSs + PROD Subnets * Firewalls implemented through Security Groups (cloud based platforms) - firewall rules delegated to product teams

I would be interested to see what other patterns teams are using and how security and operations protections are achieved.

dmourati
Absolutely must separate. One reason: controlled access to prod. You cannot let any arbitrary untrusted device on your corporate network connect directly to prod instances. You rather need a VPN or other jump host in the middle.

Same rules don't apply in dev and are counter productive there.