ZeusK8s
Seguridad y RBAC

Access keys metidos en las imágenes. Roles sobre-permisados. La auditoría los encontrará antes que tú.

La mayoría de problemas de seguridad en Kubernetes no son exóticos — son una clave de larga vida que se suponía temporal, un rol con permisos que nadie acotó y una network policy que nunca se escribió. Zeus arregla los defaults para que no descubras esto en un incidente o una auditoría.

Cloud IAM

Cada servicio obtiene su propia identidad. Sin claves estáticas.

El approach estándar es un access key de larga vida en la imagen, o un rol compartido que usa cada servicio porque acotarlos uno a uno es demasiado trabajo. Ambos van bien hasta que no — una clave rotada mal, un breach que pivota por todo porque el blast radius era la cuenta entera.

Zeus cablea workload identity para cada servicio: los pods asumen roles IAM en AWS vía IRSA, o se autentican como service accounts de GCP vía Workload Identity. Las credenciales son de corta vida, se rotan automáticamente y están acotadas a exactamente lo que el servicio necesita. Nada se mete en la imagen. Nada que rotar a mano.

Eliges el rol en la pestaña Identities del servicio. Zeus cablea la relación de trust y las annotations automáticamente. Todo es visible en cada clúster en un solo sitio — no reconstruido desde dos consolas cloud.

Zeus · Service identities
Cloud identities
Short-lived credentials · scoped per service · no static keys
Add identity
api-gateway
billing
analytics
worker
report-exporter
image-processor
+ New
api-gateway
AWS · IRSA
IAM Role
arn:aws:iam::123456789012:role/api-gateway-s3-read
Annotation wired by Zeus
eks.amazonaws.com/role-arn:
arn:aws:iam::123456789012:role/api-gateway-s3-read
Trust relationship
Principal:
  Federated: oidc.eks…/id/ABC123
Condition:
  sub: system:serviceaccount:prod:api-gateway
✓ Active · credentials rotate automatically · nothing stored in image
Controles de seguridad

Los controles que importan, cableados por defecto.

RBAC de mínimo privilegio, visual

Define ServiceAccounts, Roles y bindings en una matriz de permisos en lugar de escribir a mano YAML que necesitarías otra herramienta para auditar. Ve quién puede hacer qué de un vistazo.

Límites de red duros por defecto

Cada clúster y sitio está aislado por defecto. Nada se conecta hasta que lo permites explícitamente. Cada grant es unidireccional, opcionalmente limitado a puertos y revocable en un clic. El mapa mostrado es exactamente lo aplicado.

Hardening de pods de serie

Corre como non-root, filesystem root read-only, capabilities dropadas: el security context es parte de la definición del servicio, no una ocurrencia tardía que alguien añade tras un finding.

Scanning de imágenes antes del deploy

Las imágenes construidas aterrizan en Harbor y Trivy las escanea automáticamente. Una imagen sin escanear o que falla no se puede promover a producción — el gate está en el pipeline, no es un check manual.

Compliance

Etiqueta un clúster HIPAA. Zeus activa los controles.

La mayor parte del trabajo de compliance es la misma checklist cada vez: cifrado en reposo, networking default-deny, audit logging, rotación de claves, controles de acceso. Zeus convierte esa checklist en un tag de clúster. Los controles se activan automáticamente — obtienes un rastro de evidencia, no un proyecto de implementación manual.

HIPAA

Cifrado en reposo y en tránsito, logging de acceso, aislamiento de red y rotación de claves — activados cuando etiquetas el clúster.

PCI DSS

Networking default-deny, audit trails, scanning de imágenes y hardening de pods aplicados de forma consistente en clústeres in-scope.

SOC 2

Audit logging, controles de acceso, segmentación de red y export de evidencia para tu auditor — sin montar la recolección de evidencia tú.

Los presets de compliance están disponibles en el plan Enterprise. Configuran los controles — tu auditor sigue revisando el output, que es el punto.