Security Architecture

Yamlr is architected for high-fidelity manifest auditing within secure environments. The engine follows a local-first, zero-data egress execution model.

1. Zero-Data Egress (Local-First Processing)

Unlike SaaS platforms that require you to authenticate your Git repositories or upload manifests to their servers for analysis, Yamlr never exfiltrates code.

1. The Yamlr binary processes the abstract syntax tree entirely in-memory on your local machine or CI runner.
2. The core OpenAPI K8s Catalogs are bundled locally inside the binary itself.
3. Health dashboards and project metrics (yamlr stats) are stored in local SQLite instances within .yamlr/.
4. Anonymized Metadata (Pulse): For Pro license verification and ROI calculation, the engine emits a minimal, anonymized heartbeat ("Pulse") containing resource counts and issue categories. No manifest content, IP addresses, or PII ever leave the local environment.

This guarantees 0.00 network ingress/egress latency, allowing for massive scale and immediate InfoSec compliance.

2. The Enterprise Guardrail

Yamlr includes hardcoded logic to prevent dangerous "Ghost Healing" drift by inexperienced developers.

1. Any attempt to batch-heal over 10 files triggers an internal Confirmation Gate, requiring explicit user oversight for large-scale mutations.
2. The engine uses a 3-tier verification model to certify the integrity of every change:
   • Indentation Physicist: Validates YAML syntax and structural indentation.
   • Schema Validator: Certifies compliance against the target Kubernetes version catalog.
   • Relational Analyzer: Validates cross-resource references via the ResourceGraph.

Yamlr only marks a manifest as HEALED if all three internal verification tiers return a success state.

3. Zero-Trust Hardening & Injection (Pro)

Beyond structural analysis, Yamlr Pro includes an automated security mutation engine to instantly enforce Zero-Trust standards across legacy architectures.

Using yamlr heal . --harden, the engine can interactively repair codebases by injecting:

1. Identity Contexts: Explicit runAsNonRoot: true configurations.
2. Filesystem Locks: readOnlyRootFilesystem: true injections.
3. Privilege Revocation: Explicit capability drops (drop: ["ALL"]).
4. Network Isolations: Automatically generating and writing "Default Deny" NetworkPolicy objects for unbounded namespaces.

Global Boundary Configurations

Platform managers can strictly enforce architectural limits through the .yamlr.yaml global config:

• Trusted Registries: Scan and reject deployments pulling from DockerHub natively. Limit pulls to your internal imageRegistry: my-company.jfrog.io.
• Allowed Host Paths: Prevent malicious sandbox escapes by allowing ONLY specific volume mount domains (e.g., /var/log).