Policy as Code

1) Qué considerar «política»

• Acceso/autorización: RBAC/ABAC, ReBAC, exportación de datos, step-up (MFA).
• Seguridad de la infraestructura: control de administración de Kubernetes, política de imágenes/secretos, reglas de red.
• Cumplimiento y privacidad: gestión de consentimiento, tegiación PII, día de presentación de informes locales, restricciones geográficas.
• Configuraciones y calidad: «prohibición: latest», límites de recursos, etiquetas de recursos obligatorias (Cloud).
• Datos y ML: prohibición de formación en kits sin consentimiento, k-anonimato, presupuestos DP, Data Lineage invariantes.

2) Modelo arquitectónico PaC

PA (Punto de administración de políticas): repositorio y procesos de administración (MR/PR, rugido, versión).
PDP (Policy Decision Point): motor que calcula la solución de políticas (OPA, Cedar-engine, propio intérprete).
PEP (Policy Enforcement Point): punto de aplicación (API-gateway, webhook-almirante en K8s, ETL-transformer, SDK).
Punto de información de políticas (PIP): fuentes de atributos/hechos: IdP, directorios de recursos, almacén de datos, score de riesgo.
Decision Log/Audit: registros de soluciones inmutables (para análisis de incidentes y cumplimiento).

Flujo: consulta → PEP forma el contexto → PDP carga los hechos (PIP) → calcula la solución → PEP aplica (allow/deny/edición) → el registro/métricas.

3) Herramientas y dominios

OPA/Rego es un motor universal y lenguaje para políticas declarativas (webhook-almirancia en K8s: Gatekeeper, en CI - Conftest, en API - sidecar/servicio).
Kyverno son políticas declarativas para Kubernetes en YAML, parche/validación/generación.
Cedar (AWS/transferible) es un lenguaje de políticas que se centra en la autorización de «alguien más de lo que hace».
Cloud IAM (AWS/GCP/Azure) - Políticas de recursos en la nube (preferiblemente check-in PaC estática y en planes IaC).
Custom - Reglas DSL/sobre JSON/SQL para específicos (por ejemplo, cumplimiento ML).

4) Ciclo de vida de la política

1. Definición de Propósito y Dominio: «Prohibición de cargar contenedores con vulnerabilidades High/CRITICAL».
2. Formalización en código: Rego/Cedar/YAML.
3. Pruebas: tablas de la verdad, casos negativos, property-based.
4. Chequeos CI: linter, unit, integración en manifiestos/solicitudes ficticias.
5. Lanzamiento y distribución: publicación en bundle, firma, entrega en PDP/edge.
6. Monitoreo: hit-rate, latency p95/p99, share deny, drift dashboards.
7. Excepciones/waivers: de tiempo/volumen limitado, con auditoría y propietario.
8. Refactorización y archivo: versiones, compatibilidad, migraciones.

5) Almacenamiento y distribución

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Versioning: semver y 'policy _ version' en las respuestas PDP.
Bundles: paquetes comprimidos de políticas + esquemas + configuraciones firmados (seguridad de cadena de suministro).
Distribución: pull (PDP saca de registry/S3) o push (el controlador envía).
Evaluación parcial: anticipación de políticas para una ejecución rápida en el perímetro.

6) Modelo de datos y esquema

Contrato único de contexto: 'subject', 'resource', 'action', 'env', 'legal'.
JSON-Schema/Protobuf: validar modelos de hecho; la no coincidencia de esquemas es la razón para «indeterminate → deny».
Normalización de atributos: nombres unificados (por ejemplo, 'tenant _ id', 'risk _ level', 'pii _ tags',' image. vulns`).

7) Rendimiento y confiabilidad

Caché de soluciones: clave '(subject_hash, resource_key, acción, policy_version)'; TTL corto, invalidez por eventos (cambio de roles/etiquetas).
Hechos locales: no tire de los pesados PIP en la ruta caliente - sincronice los snapshots.
Fail-open vs fail-closed: seguridad de dominios críticos - fail-closed; para UX-crítico - degradación (revisión en lugar de deny).
Presupuesto de latencia: objetivo '<3-10 ms' para la solución en memoria PDP,' <30-50 ms' con PIP.

8) Gestión de excepciones (waivers)

Limitado en el tiempo (por ejemplo, 7 días), con el propietario obligatorio y la razón.
Cooptado: por recurso/proec/neymspace; la prohibición de los globales «para siempre».
Auditoría y recordatorios: informes sobre waiver 'am caducado, cierre automático/escalada.

9) Métricas y observabilidad

Policy Coverage: proporción de paths/endpoints protegidos por PaC.
Decision Latency / QPS / Error rate.
Nota de Deny y False Positive/Negative (a través del modo «dry-run/shadow»).
Drift: discrepancia entre el plan (IaC) y el hecho (live), entre SDK y soluciones de servidor.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Anti-patrones

Políticas «cosidas» en código sin versiones ni pruebas.
La falta de esquemas/validación de contexto → soluciones impredecibles.
Un archivo monolítico "mega. rego».
No hay un proceso de excepciones → «rondas manuales» y caos.
Sólo aplicación runtime sin «mayúscula-izquierda» en CI (fallas tardías).
Efectos de lado ocultos en la política (la política debe ser una función pura).

11) Ejemplos

11. 1 Rego (OPA): prohibición de imágenes vulnerables en K8s

rego package k8s. admission. vulns

deny[msg] {
input. kind. kind == "Pod"
some c img:= input. request. object. spec. containers[c].image vulns:= data. registry. scan [img] # actual-snapshot from PIP count ({v     v:= vulns[_]; v.severity == "CRITICAL"}) > 0 msg:= sprintf("image %s has CRITICAL vulns", [img])
}

11. 2 Rego: exportación de datos sólo con MFA y por IP «blancas»

rego package api. export

default allow = false

allow {
input. action == "export"
input. subject. mfa_verified == true net. cidr_contains("203. 0. 113. 0/24", input. env. ip)
}

11. 3 Cedar: leer sólo al propietario o miembros del equipo

cedar permit(
principal in Group::"team_members",
action in [Action::"read"],
resource in Photo::"")
when { resource. owner == principal          resource. team_id in principal. team_ids };

11. 4 Kyverno (YAML): la prohibición ':latest ' y obyaz. recursos

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: disallow-latest-and-require-limits spec:
validationFailureAction: Enforce rules:
- name: disallow-latest match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image tag 'latest' is not allowed."
pattern:
spec:
containers:
- name: ""
image: "!:latest"
- name: require-limits match: { resources: { kinds: ["Pod"] } }
validate:
message: "resources. limits.{cpu,memory} required."
pattern:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"

11. 5 Conftest en CI para el Plan Terraform

bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform

12) Incrustación en capacidades existentes

RBAC/ABAC: PaC - capa de declaración; El PDP/PEP del artículo sobre el motor de rol se vuelve a usar.
Gestión de consentimiento: política de «ads/personalización» como condiciones de acceso a datos/endpoints.
Anonimización/PII: las políticas prohíben la formación/exportación sin perfiles de anonimato y presupuesto DP.
Enrutamiento geo: política de enrutamiento de tráfico/datos por región de almacenamiento.

13) Procesos y personas

Propietarios de políticas de dominio: seguridad, plataforma, datos, producto/marketing.
Revuers: titulidades + propietarios de dominios.
Directorio de políticas: descripción del objetivo, riesgo, SLO, contacto, ejemplos, referencias de incidentes.
Entrenamiento: guydas y snippets para desarrolladores (cómo escribir pruebas, cómo depurar Rego).

14) Check-list del arquitecto

1. ¿Ha definido un conjunto mínimo de dominios y owners?
2. ¿Repositorio de políticas con pruebas, linter y CI?
3. ¿Se colocan PDP/PEP en el perímetro, en la API, en la K8s y en las pipelines de datos?
4. ¿Hay esquemas de contexto y validación?
5. ¿Firma y entrega de pandillas, estrategia de caché y discapacidad?
6. ¿Métricas (latency, deny, drift), registro de decisiones y auditoría?
7. ¿Proceso de excepción con TTL e informes?
8. ¿Dry-run/shadow-mode antes de Enforce?
9. ¿Evaluación parcial/pre-compilación para senderos «calientes»?
10. ¿Un runbook de degradación (fail-closed/allow-with-redaction)?

Conclusión

Policy as Code hace que las reglas sean reproducibles, verificables y manejables según los mismos principios que la aplicación: código-rugido, pruebas, CI/CD, métricas y retrocesos. Al conectar el PaC con la autorización (RBAC/ABAC), el cumplimiento y la seguridad de la plataforma, obtiene un circuito único, predecible y escalable para la gestión del comportamiento del sistema, desde el control de admision hasta las exportaciones de datos y los pipelines ML.