Weave Networking Security Hardening and Best Practices

Introduction to Weave Net Security

Weave Net is a popular container networking solution that creates a virtual network across multiple hosts, enabling containers to communicate seamlessly. While Weave Net simplifies container networking, its default configuration prioritizes ease of use over security. In production environments, hardening Weave Net is essential to prevent unauthorized access, data exfiltration, and lateral movement between containers.

This tutorial covers the security architecture of Weave Net, common vulnerabilities in default deployments, and actionable hardening techniques you can apply to your cluster today.

Why Weave Net Security Matters

Weave Net operates by creating an overlay network that spans multiple hosts. By default, it uses peer-to-peer connections that can expose sensitive traffic if left unencrypted. Key security concerns include:

• Unencrypted inter-host traffic: Container traffic between hosts travels in plaintext by default.
• Open peer discovery: Without authentication, rogue nodes could join the network.
• Exposed control plane: The Weave API and DNS endpoints can be accessed without restrictions.
• Privileged container deployment: Weave agents require elevated privileges, creating attack surface.

A compromised Weave network can allow attackers to intercept traffic, inject malicious containers, or pivot between isolated workloads. Hardening each layer mitigates these risks.

Understanding Weave Net's Security Architecture

Components and Their Attack Surfaces

Weave Net consists of several components, each with distinct security considerations:

• Weave Router: Handles packet forwarding between peers. Listens on ports 6783 (TCP/UDP) and 6784 (UDP).
• Weave DNS: Provides service discovery on port 53. Can leak container names and topology.
• Weave API: REST API on port 6784 for control operations. Must be restricted.
• IPAM (IP Address Management): Allocates IPs to containers. A rogue IPAM client could exhaust the address pool.

Default vs. Hardened Configuration

The default Weave deployment assumes a trusted network environment. A hardened deployment adds encryption, authentication, network policies, and monitoring. The table below summarizes the differences:

| Feature              | Default         | Hardened                |
|---------------------|-----------------|-------------------------|
| Inter-host traffic  | Plaintext       | Encrypted (NaCl)        |
| Peer authentication | None            | Trusted peers / password|
| API access          | Open (localhost)| Restricted + TLS        |
| DNS exposure        | All interfaces  | Internal only           |
| Network policies    | Allow all       | Default deny            |

Enabling Encryption Between Peers

The most critical hardening step is encrypting traffic between Weave peers. Weave Net uses NaCl (Networking and Cryptography Library) for symmetric encryption. Enable it with the --password flag.

Launching Weave with Encryption

# Set a strong password as an environment variable
export WEAVE_PASSWORD="a-very-strong-and-random-password-here"

# Launch weave with encryption enabled
weave launch --password "$WEAVE_PASSWORD"

# Verify encryption is active
weave status | grep -i encrypt

When using the password flag, all peers must use the same password. Any peer with a mismatched password will be rejected. Store the password in a secrets manager rather than hardcoding it in scripts.

Using a Password File for Kubernetes Deployments

In Kubernetes environments, pass the password via a Kubernetes Secret mounted as a file:

apiVersion: v1
kind: Secret
metadata:
  name: weave-net-pass
  namespace: kube-system
type: Opaque
stringData:
  weave-pass: "a-very-strong-and-random-password-here"
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: weave-net
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: weave
        command:
        - /home/weave/launch.sh
        env:
        - name: WEAVE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: weave-net-pass
              key: weave-pass
        - name: EXTRA_ARGS
          value: "--password=$(WEAVE_PASSWORD)"

Restricting Peer Connections with Trusted Peers

By default, Weave accepts connections from any peer that knows the network. To prevent rogue nodes from joining, use the --trusted-subnets flag to whitelist allowed peer IPs.

# Only allow peers from specific subnets
weave launch --trusted-subnets 10.0.1.0/24,10.0.2.0/24

# Connect to existing peers explicitly
weave connect 10.0.1.10 10.0.1.11

# Verify connected peers
weave status peers

Combine trusted subnets with encryption for defense in depth. Even if an attacker knows the password, they cannot join from an untrusted subnet.

Securing the Weave Control Plane

Binding to Localhost

The Weave API listens on all interfaces by default. Restrict it to localhost to prevent remote access:

# Bind the API to localhost only
weave launch --api-addr 127.0.0.1:6784

# Verify the binding
netstat -tlnp | grep 6784
# Expected: 127.0.0.1:6784

Firewall Rules for Weave Ports

Apply iptables rules to restrict access to Weave ports. Only peer hosts should reach ports 6783 and 6784:

# Allow Weave traffic only from trusted peer subnet
iptables -A INPUT -p tcp --dport 6783 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 6783 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 6784 -s 10.0.1.0/24 -j ACCEPT

# Drop all other Weave traffic
iptables -A INPUT -p tcp --dport 6783 -j DROP
iptables -A INPUT -p udp --dport 6783 -j DROP
iptables -A INPUT -p udp --dport 6784 -j DROP

# Save rules
iptables-save > /etc/iptables/rules.v4

Implementing Network Policies

Weave Net supports Kubernetes NetworkPolicy natively, enabling microsegmentation between workloads. Implementing a default-deny posture is one of the most effective security controls.

Default Deny All Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Allow Specific Traffic Patterns

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Isolating Namespaces

Prevent cross-namespace communication by combining namespace selectors with pod selectors:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: production
    ports:
    - protocol: UDP
      port: 53

Label your namespaces to make selectors work:

kubectl label namespace production name=production
kubectl label namespace staging name=staging

Securing Weave DNS

Weave DNS exposes container service names, which can leak infrastructure details. Restrict DNS to internal interfaces only:

# Launch Weave with DNS bound to the weave bridge only
weave launch --dns-domain=internal.cluster.local \
  --dns-listen-address 10.32.0.1:53

# Verify DNS is not exposed externally
netstat -tulnp | grep :53

Additionally, configure your containers to use only the Weave DNS resolver and block external DNS queries at the firewall level for sensitive workloads.

Reducing Privileges for Weave Components

The Weave DaemonSet runs with significant privileges. While some are necessary (NET_ADMIN, SYS_ADMIN for networking operations), you can reduce the attack surface by applying security contexts:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: weave-net
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: weave
        securityContext:
          privileged: true
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            add:
            - NET_ADMIN
            - NET_RAW
            - SYS_ADMIN
            drop:
            - ALL
        volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: var-run
          mountPath: /var/run
      volumes:
      - name: tmp
        emptyDir: {}
      - name: var-run
        hostPath:
          path: /var/run

The readOnlyRootFilesystem setting prevents attackers from writing malicious binaries to the container filesystem if they compromise the Weave process.

Monitoring and Auditing Weave Net

Connection Logging

Enable connection tracking to audit which peers connect to your network:

# Enable verbose peer connection logging
weave launch --log-level=debug

# Monitor peer connections in real time
journalctl -u weave -f | grep -i "peer.*connect"

# Check for unauthorized connection attempts
journalctl -u weave --since "1 hour ago" | grep -i "reject\|deny\|auth"

Prometheus Metrics for Security Monitoring

Weave Net exposes metrics on port 6782. Configure Prometheus to scrape and alert on suspicious patterns:

# prometheus-weave-rules.yaml
groups:
- name: weave-security
  rules:
  - alert: WeavePeerDisconnects
    expr: rate(weave_peer_connections[5m]) < 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Weave peer disconnecting frequently"
      description: "Peer {{ $labels.peer }} is disconnecting repeatedly"

  - alert: WeaveEncryptionDisabled
    expr: weave_encryption_enabled == 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Weave encryption is disabled"
      description: "Inter-host traffic is unencrypted on this node"

Best Practices Summary

• Always enable encryption with a strong password stored in a secrets manager.
• Use trusted subnets to restrict which hosts can join the Weave network.
• Bind the control API to localhost and never expose it externally.
• Apply firewall rules to limit Weave ports to known peer IPs only.
• Implement default-deny network policies and explicitly allow only required traffic flows.
• Isolate namespaces using network policies to prevent lateral movement.
• Restrict DNS exposure to internal interfaces only.
• Apply security contexts with read-only root filesystems and minimal capabilities.
• Monitor peer connections and set up alerts for unauthorized access attempts.
• Rotate the Weave password periodically and update all peers simultaneously.
• Keep Weave Net updated to the latest stable version to receive security patches.
• Audit network policies regularly using tools like kubectl-who-can and policy scanners.

Conclusion

Weave Net provides powerful container networking capabilities, but its default configuration leaves significant security gaps that can expose your infrastructure to attacks. By enabling encryption, restricting peer connections, securing the control plane, implementing network policies, and continuously monitoring your deployment, you can transform Weave Net from a convenience tool into a production-grade secure networking solution. Security hardening is not a one-time task — it requires ongoing attention as your cluster grows and evolves. Start with encryption and network policies, then layer additional controls based on your threat model and compliance requirements. The effort invested in hardening Weave Net pays dividends by protecting your workloads, preventing lateral movement, and ensuring your container infrastructure remains resilient against both external and internal threats.