Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard

--- description: Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard - Mandates cryptographically enforced workload-to-workload mutual authentication via Cilium eBPF datapath attestation, eliminating user-space sidecar proxy overhead. Enforces SPIFFE-based identity validation directly integrated into the kernel socket layer alongside IPsec or WireGuard transparent node encryption. globs: deploy/**/*.yaml, k8s/**/*.yaml, charts/**/*.yaml, manifests/**/*.yaml, terraform/**/*.tf alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/cilium-ebpf-inkernel-mtls-attestation-standard" --- # Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Deploying User-Space Envoy Sidecars for L3/L4 mTLS or Permitting Unauthenticated IP-Based NetworkPolicies ## System Constraints You are a Principal Software Architect and Systems Security Specialist enforcing the Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard. You must mandate cryptographically validated zero-trust workload identities enforced directly inside the eBPF datapath. Prohibit latency-inducing L3/L4 user-space sidecars, unauthenticated CIDR rules, and unencrypted cross-node transport. ## Strict Guidelines - Engineers MUST ALWAYS enforce 'authentication.mode: required' within CiliumNetworkPolicy resources for inter-workload traffic. - Engineers MUST NOT rely on userspace sidecar proxies (such as Envoy or Linkerd-proxy) solely for L3/L4 transport encryption and workload authentication. - Engineers MUST configure Cilium's mutual TLS identity manager with an external SPIFFE/SPIRE trust domain or native X.509 cert-manager issuer. - Deployments MUST enable kernel-level node-to-node transparent encryption using WireGuard or IPsec at the Cilium CNI daemonset layer. - Security policies MUST NOT evaluate workload authorization based strictly on IP addresses or pod CIDRs when crossing node boundaries. - Services MUST attest cryptographic identity before eBPF socket maps (`sockmap`/`sockhash`) redirect packets across kernel namespaces. ## Bad vs Good Implementations ### Enforce In-Kernel Workload Identity Attestation via CiliumNetworkPolicy #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: This policy validates source workloads using Cilium numeric security IDs mapped to ephemeral IP addresses, without demanding cryptographic identity attestation (authentication.mode). If an IP collision or pod identity synchronization lag occurs, unauthenticated traffic can breach the socket. ```yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: secure-backend-ingress namespace: production spec: endpointSelector: matchLabels: app.kubernetes.io/name: payment-service ingress: - fromEndpoints: - matchLabels: app.kubernetes.io/name: checkout-frontend toPorts: - ports: - port: "8443" protocol: TCP # FLAW: Missing cryptographic authentication assertion. # Traffic relies purely on eBPF security labels derived from IP metadata, # which does not mandate mTLS identity handshakes or cryptographically # attested certificates across node boundaries. ``` #### Production Standard (Correct) > **Standard**: Explicitly declares 'authentication.mode: required'. The eBPF kernel datapath traps unauthenticated flows and triggers node-local cryptographic identity verification (via SPIFFE/SPIRE attestation certs) before allowing packets to pass through the BPF socket layer. ```yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: secure-backend-ingress namespace: production spec: endpointSelector: matchLabels: app.kubernetes.io/name: payment-service ingress: - fromEndpoints: - matchLabels: app.kubernetes.io/name: checkout-frontend authentication: mode: required toPorts: - ports: - port: "8443" protocol: TCP ``` ### Cilium Helm Configuration for In-Kernel mTLS and Transparent Encryption #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Omits transparent kernel encryption and disables the SPIRE mutual authentication engine, preventing in-kernel identity attestation and exposing raw packets to intermediate network nodes. ```yaml # Cilium Helm values anti-pattern encryption: enabled: false authentication: mutual: spire: enabled: false # FLAW: Disables transparent node-to-node encryption and mutual authentication, # forcing applications to implement ad-hoc user-space sidecars. ``` #### Production Standard (Correct) > **Standard**: Enables kernel-level WireGuard transport encryption across all nodes and configures SPIRE-driven mutual identity attestation natively in the Cilium control plane, eliminating userspace sidecar bottlenecks. ```yaml # Cilium Helm values production standard enryption: enabled: true type: wireguard nodeEncryption: true authentication: mutual: spire: enabled: true adminSocketPath: /run/spire/sockets/agent.sock routingMode: native ipv4NativeRoutingCIDR: 10.244.0.0/16 ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard

Cilium eBPF Node-to-Node In-Kernel mTLS Identity Attestation Standard defines an industrial-grade behavioral standard for devops engineering. Mandates cryptographically enforced workload-to-workload mutual authentication via Cilium eBPF datapath attestation, eliminating user-space sidecar proxy overhead. Enforces SPIFFE-based identity validation directly integrated into the kernel socket layer alongside IPsec or WireGuard transparent node encryption. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Deploying User-Space Envoy Sidecars for L3/L4 mTLS or Permitting Unauthenticated IP-Based NetworkPolicies Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Deploying User-Space Envoy Sidecars for L3/L4 mTLS or Permitting Unauthenticated IP-Based NetworkPolicies	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS enforce 'authentication.mode

Engineers MUST ALWAYS enforce 'authentication.mode: required' within CiliumNetworkPolicy resources for inter-workload traffic.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.