Security Architecture

Yamlr was architected from the ground up to protect high-value proprietary infrastructure code. We serve as the "Strategic Shield" for enterprise Platform Engineering teams.

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 written to SQLite instances locally in .yamlr/.
4. No telemetry, statistics, or metrics are sent upstream.

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 consecutively triggers the internal Enterprise Guardrail, enforcing confirmation checks to ensure the user intends to mutate a large-scale repository.
2. An interactive, 3-tier status line monitors the integrity of every physical change:
   • [PHY] - Physics layer (Syntax errors, indentation repairs).
   • [KBS] - Schema layer (OpenAPI structure validation).
   • [SEM] - Semantic layer (ResourceGraph reference links and Logic constraints).

Yamlr refuses to label a run as HEALED ✨ until all active tiers turn green, meaning the engine must confidently assert a successful kubectl apply.

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).