Neuwerk

Policy Examples

Copyable policy starting points for common tasks such as narrow egress, hostname policy, TLS-aware policy, and Kubernetes-backed sources.

Use this page as a cookbook of starting points. Every example here matches the current policy schema, but you should still narrow the source ranges, destinations, and modes for your own environment.

Unless noted otherwise, each example is shown as the full request body for:

PUT /api/v1/policies/by-name/{name}

1. Narrow HTTPS Egress For One CIDR

This allows one source CIDR to reach one HTTPS destination and denies everything else.

{
  "mode": "enforce",
  "name": "office-egress",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "branch-office",
        "sources": {
          "cidrs": ["10.10.0.0/16"]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-web",
            "action": "allow",
            "match": {
              "dst_ips": ["203.0.113.10"],
              "proto": "tcp",
              "dst_ports": [443]
            }
          }
        ]
      }
    ]
  }
}

Use this as the safest first policy pattern: explicit sources, explicit destination, deny fallbacks.

2. Hostname-Based Policy For One Source Group

This pattern shows the important hostname-policy rule: the Neuwerk needs explicit DNS allow rules, not just packet allow rules.

{
  "mode": "enforce",
  "name": "hostname-egress",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "office-users",
        "sources": {
          "cidrs": ["10.20.0.0/16"]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-example-dns",
            "action": "allow",
            "match": {
              "dns_hostname": "^api\\.example\\.com$"
            }
          },
          {
            "id": "allow-example-https",
            "action": "allow",
            "match": {
              "proto": "tcp",
              "dst_ports": [443]
            }
          }
        ]
      }
    ]
  }
}

Warning: packet policy alone does not grant hostname access. The DNS rule is what lets the Neuwerk resolve and allowlist the destination IP.

3. Audit-First Rollout

Use the same policy logic you intend to enforce, but start at the top level in audit mode.

{
  "mode": "audit",
  "name": "candidate-policy",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "test-scope",
        "sources": {
          "cidrs": ["10.30.0.0/24"]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-https",
            "action": "allow",
            "match": {
              "proto": "tcp",
              "dst_ports": [443]
            }
          }
        ]
      }
    ]
  }
}

After reviewing the audit evidence, promote the same policy to mode: "enforce".

4. TLS Metadata Match On SNI

Use metadata mode when SNI or certificate fields are enough and you do not want full interception.

{
  "mode": "enforce",
  "name": "tls-metadata",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "tls-users",
        "sources": {
          "cidrs": ["10.40.0.0/24"]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-api-sni",
            "action": "allow",
            "match": {
              "dst_ips": ["203.0.113.20"],
              "proto": "tcp",
              "dst_ports": [443],
              "tls": {
                "mode": "metadata",
                "sni": {
                  "exact": ["api.example.com"]
                }
              }
            }
          }
        ]
      }
    ]
  }
}

5. TLS Intercept For A Narrow HTTP Path

Use intercept mode only when you need HTTP-aware policy inside TLS and clients trust the intercept CA.

{
  "mode": "enforce",
  "name": "tls-intercept-http",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "intercept-users",
        "sources": {
          "cidrs": ["10.50.0.0/24"]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-admin-api",
            "action": "allow",
            "match": {
              "proto": "tcp",
              "dst_ports": [443],
              "tls": {
                "mode": "intercept",
                "http": {
                  "request": {
                    "host": {
                      "exact": ["api.example.com"]
                    },
                    "methods": ["GET"],
                    "path": {
                      "prefix": ["/admin/"]
                    }
                  }
                }
              }
            }
          }
        ]
      }
    ]
  }
}

6. Kubernetes-Backed Source Group

Use this when source identity should follow pods instead of static IP lists.

{
  "mode": "enforce",
  "name": "payments-egress",
  "policy": {
    "default_policy": "deny",
    "source_groups": [
      {
        "id": "payments-pods",
        "sources": {
          "kubernetes": [
            {
              "integration": "cluster-a",
              "pod_selector": {
                "namespace": "payments",
                "match_labels": {
                  "app": "api"
                }
              }
            }
          ]
        },
        "default_action": "deny",
        "rules": [
          {
            "id": "allow-webhook",
            "action": "allow",
            "match": {
              "proto": "tcp",
              "dst_ips": ["203.0.113.20"],
              "dst_ports": [443]
            }
          }
        ]
      }
    ]
  }
}

How To Use These Safely

  • start with the narrowest possible source scope
  • prefer top-level audit mode before broad enforcement
  • add explicit DNS rules when hostname policy is involved
  • verify readiness and runtime state after every write