Network and policy repositories — separate repositories for network and policy configuration

Application configuration, network configuration, and policy configuration are three kinds of code with three different blast radii. An application change breaks one workload. A network change can open a path that exposes every workload in a VPC. A policy change can grant a permission that violates a regulatory boundary. The repository layout must encode that difference, and the encoding is separate repositories.

Why network and policy are separate

flowchart LR
    APP["infra-app"]
    NET["infra-network"]
    POL["infra-policy"]
    APP -->|consumes| NET
    APP -->|consumes| POL

• Blast radius. A network change can open a public CIDR, attach a security group that grants SSH from 0.0.0.0/0, or remove a route that breaks east-west traffic.
• Reviewer surface. Network reviewers are network engineers; policy reviewers are security engineers. CODEOWNERS is most reliably enforced at the repository boundary.
• Audit and compliance. A regulator needs a single repository whose history is the answer. Conflating produces a single history that has to be filtered every time.

The network repository

A infra-network repository holds VPCs, subnets, route tables, NAT gateways, peering connections, security groups, network ACLs, DNS zones. The layout follows the Terraform conventions from lesson 02, but the CODEOWNERS file is the differentiator:

# CODEOWNERS for infra-network
/modules/vpc/         @network-team
/modules/security/    @network-team
/environments/prod/   @network-team @security-team

Every PR that touches a network module requires a network engineer’s review, and every PR that touches a production environment requires a security engineer’s review as well. The application team that consumes the VPC module through a versioned reference cannot bypass this rule.

The policy repository

A infra-policy repository holds OPA Rego bundles, Kubernetes NetworkPolicy manifests, IAM policy documents, and Terraform Sentinel policies. The policy repository is the most sensitive of the three, because a bad policy change can grant a permission that the rest of the security model relies on denying.

# CODEOWNERS for infra-policy
/iam/                 @security-team
/opa/                 @security-team @platform-team
/network-policies/    @security-team @platform-team
/environments/prod/   @security-team

The pattern is the same as the network repository, but the reviewer pool is narrower.

The cross-repo change pattern

When an application change requires a network change, the change is two pull requests:

sequenceDiagram
    participant A as Application engineer
    participant N as Network team
    A->>N: Open PR in infra-network
    N->>N: Merge, tag release
    A->>A: Open PR in infra-app: bump tag
    A->>A: Merge, deploy

The network change is merged first, because the application change cannot be reviewed without the network change being available. The application’s PR is a submodule bump that consumes the new tag. The price of the boundary is two PRs; the benefit is that the network team cannot be bypassed.

Production discipline

1. Put network configuration in infra-network, not in infra-app. A security group module in the application repository is a security boundary violation.
2. Put policy configuration in infra-policy, not in infra-app or infra-network. OPA bundles, IAM policy documents, and NetworkPolicy manifests belong in the repository the security team owns.
3. Use CODEOWNERS at the repository root. The hosting provider enforces CODEOWNERS more reliably at the repository boundary.
4. Use the cross-repo change pattern for application changes that require network or policy changes. The network or policy PR is reviewed and merged first; the application PR is a submodule bump that consumes the new tag.
5. Tag every released network or policy module. The tag is the version; the team’s CI should produce the tag.

Cross-course references

• Linux for Production Sysadmins - Part XXXIV (NetworkHardening) covers the firewall configuration that lives in the network repository.
• Kubernetes for Production Sysadmins - Part XII (NetworkPolicies) covers the NetworkPolicy manifests that live in the policy repository.
• Terraform for Production Sysadmins - Part XII (RegistryModules) covers the versioned module reference used in the cross-repo change pattern.

Quiz