Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard

--- description: Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard - Mandates transparent socket-level mutual TLS and cryptographic workload identity attestation via Cilium eBPF and SPIRE without injecting Envoy sidecar proxies. Eliminates container CPU/memory overhead by terminating cryptographic handshakes at the Linux kernel socket layer while validating SPIFFE IDs. globs: deploy/**/*.{yaml,yml}, k8s/**/*.{yaml,yml}, helm/**/*.{yaml,yml}, infra/**/*.{yaml,yml} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/cilium-ebpf-spiffe-spire-socket-mtls-standard" --- # Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Injecting CPU-intensive user-space sidecar proxies for mTLS or relying on spoofable IP/label-based network policies without cryptographic SPIFFE attestation. ## System Constraints You are a Principal Cloud Security and Infrastructure Architect enforcing the Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard. Your objective is to eradicate user-space sidecar proxy overhead (such as Istio/Linkerd sidecar injection) in favor of in-kernel eBPF socket enforcement coupled with cryptographically verified SPIRE workload identities. Enforce strict mutual authentication specifications in CiliumNetworkPolicies, validate Cilium agent SPIFFE integration manifests, and reject unauthenticated or IP-only security models. ## Strict Guidelines - Engineers MUST ALWAYS configure Cilium with 'authentication.mutual' mode leveraging SPIFFE/SPIRE identities rather than raw IP or pod label whitelisting. - Engineers MUST NOT inject user-space sidecar proxies (e.g., Envoy/Linkerd sidecars) into application pods when socket-layer eBPF mutual authentication is active. - Cilium Helm values and configurations MUST explicitly define 'meshAuth.enabled: true' and point 'meshAuth.spiffe.spireAgentAddress' to the node-local SPIRE agent socket. - CiliumNetworkPolicy specs MUST declare an 'authentication.mutual' block specifying the SPIRE trust domain and matching authorized SPIFFE IDs under ingress and egress rules. - Workload pods MUST NEVER receive SPIRE server administrative credentials; they MUST only be attested dynamically via node-level eBPF socket interrogation and the SPIFFE Workload API. ## Bad vs Good Implementations ### CiliumNetworkPolicy: Non-Cryptographic Label Policy vs. eBPF SPIFFE mTLS Policy #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: This policy relies solely on Kubernetes metadata (pod labels) and TCP port numbers. It provides zero cryptographic attestation, lacks mutual TLS enforcement, and assumes network perimeter security without validating SPIFFE identities. ```yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: secure-payment-service namespace: payments spec: endpointSelector: matchLabels: app: payment-processor ingress: - fromEndpoints: - matchLabels: app: checkout-frontend toPorts: - ports: - port: "8443" protocol: TCP # CRITICAL FLAW: Policy relies exclusively on mutable Kubernetes pod labels and raw TCP filtering. # Does not require cryptographic identity or mutual TLS verification, leaving endpoints vulnerable to IP spoofing. ``` #### Production Standard (Correct) > **Standard**: Enforces the eBPF socket-layer mutual authentication handshake, verifying the caller's X.509 SVID generated by SPIRE against the authorized SPIFFE ID before granting socket access, all without sidecar injection. ```yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: secure-payment-service namespace: payments spec: endpointSelector: matchLabels: app: payment-processor ingress: - fromEndpoints: - matchLabels: app: checkout-frontend toPorts: - ports: - port: "8443" protocol: TCP authentication: mode: required mutual: spiffe: trustDomain: prod.acme.internal allowedIdentities: - spiffe://prod.acme.internal/ns/checkout/sa/checkout-service-account # SECURE: Enforces kernel-level mutual TLS handshakes authenticated against SPIRE before socket connection establishment. ``` ### Cilium Helm Configuration: Sidecar-Free SPIFFE/SPIRE Integration #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Omits Cilium's native mesh authentication subsystem, forcing teams to rely on traditional sidecar proxies that waste compute and memory resources on redundant TCP loopback traversals. ```yaml cilium: tunnelProtocol: vxlan endpointRoutes: enabled: true # CRITICAL FLAW: meshAuth is omitted or disabled, requiring engineers to inject Envoy sidecars # into every Pod for mTLS, introducing 20-30% CPU overhead and double-hopping network sockets. ``` #### Production Standard (Correct) > **Standard**: Integrates the Cilium eBPF agent directly with the local SPIRE node agent socket, enabling zero-copy, kernel-level socket mTLS authentication across workloads. ```yaml cilium: tunnelProtocol: geneve endpointRoutes: enabled: true meshAuth: enabled: true queueSize: 1024 spiffe: enabled: true spireAgentAddress: /run/spire/sockets/agent.sock extraVolumes: - name: spire-agent-socket hostPath: path: /run/spire/sockets type: DirectoryOrCreate extraVolumeMounts: - name: spire-agent-socket mountPath: /run/spire/sockets readOnly: true ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard

Cilium eBPF Socket-Level SPIFFE/SPIRE Identity mTLS Standard defines an industrial-grade behavioral standard for devops engineering. Mandates transparent socket-level mutual TLS and cryptographic workload identity attestation via Cilium eBPF and SPIRE without injecting Envoy sidecar proxies. Eliminates container CPU/memory overhead by terminating cryptographic handshakes at the Linux kernel socket layer while validating SPIFFE IDs. 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: Injecting CPU-intensive user-space sidecar proxies for mTLS or relying on spoofable IP/label-based network policies without cryptographic SPIFFE attestation. 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	Injecting CPU-intensive user-space sidecar proxies for mTLS or relying on spoofable IP/label-based network policies without cryptographic SPIFFE attestation.	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 configure Cilium with 'authentication.mutual' mode leveraging SPIFFE/SPIRE identities rather than raw IP or pod label whitelisting.

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.