ZeusK8s
Cloud IAM

Una clave de larga vida con alcance desconocido, sentada en cada imagen.

Así es como la mayoría de equipos gestionan el acceso cloud. Alguien necesitaba S3, así que metió un access key en una env var — y ahora esa credencial vive en cada imagen, en cada clúster, sin alcance claro y sin rotación. ZeusK8s la reemplaza con identidad de corta vida por servicio que nunca toca tus imágenes.

Mínimo privilegio que de verdad es práctico.

El acceso cloud es donde la seguridad se erosiona en silencio. Un servicio necesita leer un bucket S3, alguien mete un access key en una variable de entorno, y ahora una credencial de larga vida con quién-sabe-qué alcance está en una imagen. Multiplica por cada servicio y cada clúster.

ZeusK8s cablea workload identity de verdad. En AWS, los pods asumen roles IAM vía IRSA; en GCP, se autentican como service accounts vía Workload Identity. En ambos casos las credenciales son de corta vida, acotadas a ese servicio y nunca se almacenan. Lo configuras junto al servicio que lo necesita, no en una consola cloud aparte.

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
How it works

From zero to running.

01

Elige el rol o service account

En la pestaña Identities del servicio, elige el rol IAM de AWS o la service account de GCP que debe asumir. El permiso vive junto al workload.

02

Zeus cablea la trust

Configura la relación de trust OIDC, las annotations del ServiceAccount y los bindings automáticamente. Sin editar trust policies a mano.

03

Los pods obtienen credenciales de corta vida

En runtime el pod recibe credenciales temporales y acotadas del metadata service de la cloud. Sin access keys, nada que rotar o filtrar.

04

Audita en un solo sitio

Ve qué servicios tienen qué permisos cloud en cada clúster, en lugar de reconstruirlo desde dos consolas cloud.

The specifics

Built by people who run this in production.

No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.

AWS
IRSA: los pods asumen roles IAM vía el proveedor OIDC del clúster
GCP
Workload Identity: los pods se autentican como service accounts
Credenciales
De corta vida, acotadas, nunca almacenadas en disco
Setup
Relaciones de trust y annotations configuradas automáticamente
Kubernetes RBAC
ServiceAccount + Role + bindings en un editor en matriz
Visibilidad
Mapa de identidad por servicio en todos los clústeres
Straight answers

Questions you’d actually ask.

¿Por qué no usar simplemente access keys?

Las claves de larga vida se filtran, sobre-otorgan y nunca se rotan. Workload identity da a cada pod credenciales de corta vida y acotadas sin nada que robar de una imagen. Es el modelo que recomiendan AWS y Google, hecho fácil aquí.

¿AWS y GCP funcionan igual en Zeus?

Los mecanismos difieren (IRSA vs Workload Identity) pero la experiencia es idéntica: eliges una identidad en la pestaña Identities del servicio, y Zeus se ocupa del cableado específico de cada cloud.

¿Esto cubre también Kubernetes RBAC?

Sí. El RBAC in-cluster (ServiceAccounts, Roles, bindings) se configura en una matriz de permisos en el mismo servicio, así que permisos cloud y de clúster viven juntos.