---
checkId: check.environment.network.policy
plugin: stellaops.doctor.environment
severity: warn
tags: [environment, network, policy, security, isolation]
---
# Environment Network Policy

## What It Checks
Retrieves network policies from the Release Orchestrator (`/api/v1/environments/network-policies`) and evaluates isolation posture for each environment. The check enforces these rules:
- **Production environments must not allow ingress from dev** -- detected as critical violation
- **Production environments should use default-deny policies** -- missing default-deny is a warning
- **No environment should have wildcard ingress** (`*` or `0.0.0.0/0`) -- critical for production, warning for others
- **Wildcard egress** (`*` or `0.0.0.0/0`) is flagged as informational

Severity:
- **Fail** if any critical violations exist (prod ingress from dev, wildcard ingress on prod)
- **Warn** if only warning-level violations exist (missing default-deny, wildcard ingress on non-prod)
- **Warn** if no network policies are configured at all
- **Pass** if all policies are correctly configured

## Why It Matters
Network isolation between environments is a fundamental security control. Allowing dev-to-production ingress means compromised development infrastructure can directly attack production services. Missing default-deny policies mean any new service added to the environment is implicitly network-accessible. Wildcard ingress exposes services to the entire network or internet. These misconfigurations are common audit findings that can block compliance certifications.

## Common Causes
- Network policies not yet defined for a new environment
- Legacy policy left in place from initial setup
- Production policy copied from dev without tightening rules
- Manual firewall rule change not reflected in Stella Ops policy
- Policy update deployed to staging but not promoted to production

## How to Fix

### Docker Compose
```bash
# Review current network policies
stella env network-policy list

# Create a default-deny policy for production
stella env network-policy create prod --default-deny

# Allow only staging ingress to production
stella env network-policy update prod --default-deny --allow-from staging

# Restrict egress to specific destinations
stella env network-policy update prod --egress-allow "10.0.0.0/8,registry.internal"

# In Docker Compose, use network isolation
# Define separate networks in docker-compose.stella-ops.yml:
#   networks:
#     prod-internal:
#       internal: true
#     staging-internal:
#       internal: true
```

### Bare Metal / systemd
```bash
# Review current iptables/nftables rules
sudo iptables -L -n -v
# or
sudo nft list ruleset

# Apply default-deny for production network interface
sudo iptables -A INPUT -i prod0 -j DROP
sudo iptables -I INPUT -i prod0 -s <staging-subnet> -j ACCEPT

# Or configure via stellaops policy
stella env network-policy update prod --default-deny --allow-from staging

# Persist firewall rules
sudo netfilter-persistent save
```

### Kubernetes / Helm
```bash
# Review existing network policies
kubectl get networkpolicies -n stellaops-prod

# Apply default-deny via Helm
helm upgrade stellaops stellaops/stellaops \
  --set environments.prod.networkPolicy.defaultDeny=true \
  --set environments.prod.networkPolicy.allowFrom[0]=stellaops-staging

# Or apply a NetworkPolicy manifest directly
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: stellaops-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
EOF
```

## Verification
```bash
stella doctor run --check check.environment.network.policy
```

## Related Checks
- `check.environment.connectivity` - network policies can block agent connectivity if misconfigured
- `check.environment.drift` - network policy differences between environments are a form of drift
- `check.environment.secrets` - network isolation protects secret transmission