En arquitecturas cloud modernas, uno de los problemas más comunes no es únicamente cómo autenticar una aplicación, sino cómo hacerlo sin terminar administrando API keys, secretos permanentes y usuarios técnicos que sobreviven mucho más tiempo que el workload que los necesita.
Este problema se vuelve todavía más relevante cuando trabajamos con pipelines CI/CD, Kubernetes, arquitecturas multicloud y agentes de inteligencia artificial.
Oracle Cloud Infrastructure está abordando este escenario mediante Workload Identity Federation (WIF), permitiendo que workloads externos utilicen una identidad existente para obtener acceso temporal a recursos OCI sin depender de credenciales OCI permanentes.
En este artículo veremos qué problema resuelve, cómo funciona conceptualmente y por qué puede cambiar la manera en que diseñamos la autenticación machine-to-machine en OCI.
El problema: credenciales que viven demasiado tiempo
Imaginemos un pipeline de GitHub Actions que necesita subir un artefacto a OCI Object Storage.
Una implementación tradicional podría requerir almacenar información como:
OCI_USER_OCID
OCI_TENANCY_OCID
OCI_FINGERPRINT
OCI_PRIVATE_KEY
OCI_REGION
El pipeline funciona.
Pero ahora existe una nueva responsabilidad:
proteger la private key;
controlar quién puede leer el secret;
rotar la credencial;
eliminarla cuando deje de utilizarse;
evitar que termine dentro de una imagen, repositorio o log;
auditar qué workload utilizó realmente esa identidad.
La pregunta entonces es:
¿Por qué entregar una credencial permanente a un workload que solamente necesita acceso durante unos minutos?
Aquí aparece Workload Identity Federation.
¿Qué es OCI Workload Identity Federation?
OCI Workload Identity Federation permite que una carga de trabajo presente una identidad emitida por una plataforma externa confiable y la intercambie por acceso temporal a OCI.
Oracle describe este modelo utilizando ephemeral Resource Principal Session Tokens (RPST).
En lugar de crear permanentemente:
`Workload
↓
OCI User
↓
API Key
↓
OCI Resource
podemos utilizar:
Workload
↓
Identidad externa verificable
↓
OCI Workload Identity Federation
↓
Credencial OCI temporal
↓
OCI IAM Policy
↓
OCI Resource
`
El workload mantiene su identidad original.
OCI valida esa identidad y determina qué acciones puede realizar.
Arquitectura conceptual
Una arquitectura simplificada podría verse así:
La principal diferencia está en que OCI ya no necesita mantener una identidad permanente por cada workload externo.
Tres conceptos importantes
Oracle resume este modelo alrededor de tres resultados importantes.
- No Standing Users
No es necesario mantener un usuario OCI permanente para cada workload.
El workload obtiene una sesión efímera.
Esto puede reducir tareas como:
- alta de usuarios técnicos;
- revisiones periódicas;
- deshabilitación;
- limpieza;
- offboarding.
- No Standing Credentials
Una aplicación puede utilizar una credencial nativa y temporal de su plataforma.
Por ejemplo:
plaintext
GitHub Actions → OIDC Token
Kubernetes → Service Account Token
Cloud workload → Platform-issued identity
Después, OCI puede validar dicha identidad y emitir una sesión temporal.
Esto evita que una API key OCI de larga duración termine almacenada en:
- GitHub Secrets
- Kubernetes Secrets
- Containers
- CI/CD configuration
- Notebooks
- Agent configuration
Oracle destaca precisamente la eliminación de credenciales permanentes como uno de los principales beneficios del modelo.
- Claim-Based Authorization
Aquí encontramos uno de los puntos más interesantes.
Una identidad externa normalmente contiene claims.
En GitHub podríamos tener información relacionada con:
- organization
- repository
- workflow
- branch
- environment
- issuer
En Kubernetes podríamos identificar:
- cluster
- namespace
- service account
- issuer
- subject
Estos atributos pueden convertirse en contexto utilizado por OCI IAM para tomar decisiones de autorización.
Ya no solamente preguntamos:
¿Quién eres?
También podemos preguntar:
¿Desde qué repositorio vienes?
¿Desde qué workflow?
¿Desde qué namespace?
¿Qué ServiceAccount estás utilizando?
¿En qué ambiente estás ejecutándote?
Esto permite construir controles mucho más específicos.
Caso 1: GitHub Actions → OCI
Uno de los escenarios más interesantes es GitHub Actions.
Supongamos que tenemos:
Repository:
company/payment-api
Workflow:
deploy-production.yml
Branch:
main
El objetivo es permitir que únicamente ese workflow pueda acceder a determinados recursos de OCI.
El flujo conceptual sería:
`plaintext
Developer
│
▼
GitHub Repository
│
▼
GitHub Actions
│
│ OIDC token
▼
OCI Workload Identity Federation
│
│ temporary OCI identity
▼
OCI IAM
│
▼
Object Storage / Functions / Other OCI services
`
GitHub puede emitir un token OIDC firmado que representa el workflow.
OCI puede validar elementos como:
Issuer
Repository
Workflow
Branch
Environment
y posteriormente otorgar una identidad temporal.
¿Qué cambia desde el punto de vista de seguridad?
Modelo tradicional:
plaintext
GitHub Actions
│
▼
GitHub Secret
│
▼
OCI Private API Key
│
▼
OCI User
│
▼
OCI Resource
`
Modelo federado:
`plaintext
GitHub Actions
│
▼
GitHub OIDC Token
│
▼
OCI WIF
│
▼
Temporary RPST
│
▼
OCI IAM
│
▼
OCI Resource
`
La diferencia parece pequeña visualmente.
Arquitectónicamente es enorme.
Comparación
- Modelo con credenciales permanentes Workload Identity Federation
- API Key almacenada Token temporal
- Usuario técnico OCI Identidad del workload
- Rotación necesaria Sesión efímera
- Secrets permanentes Identidad emitida por plataforma
- Mayor superficie operacional Menor administración de credenciales
- Identidad generalmente estática Contexto mediante claims
- Difícil identificar cada ejecución Mayor granularidad potencial Caso 2: Kubernetes
Kubernetes presenta otro escenario ideal.
Normalmente nuestras aplicaciones utilizan ServiceAccounts.
Por ejemplo:
apiVersion: v1
kind: ServiceAccount
metadata:
name: payment-api
namespace: production
Tenemos entonces una identidad lógica:
Cluster:
prod-cluster
Namespace:
production
ServiceAccount:
payment-api
En lugar de entregar una API key OCI al pod:
`plaintext
Pod
↓
Kubernetes Secret
↓
OCI API Key
↓
OCI
podemos construir:
Pod
↓
ServiceAccount Token
↓
OCI Identity Federation
↓
Temporary Identity
↓
OCI IAM
↓
OCI Resource
`
Esto permite vincular autorización con el contexto real del workload.
Oracle también soporta identidades de workload directamente en OKE para proporcionar acceso detallado desde workloads Kubernetes a otros recursos OCI. En esos escenarios, la identidad está determinada por la combinación de cluster, namespace y ServiceAccount.
Ejemplo: aplicación Kubernetes accediendo a Object Storage
Imaginemos:
Application:
invoice-service
Namespace:
finance
ServiceAccount:
invoice-reader
Su único requerimiento es consultar archivos de un bucket:
finance-invoices
El principio de mínimo privilegio nos dice que deberíamos evitar:
Allow everything everywhere
y diseñar una autorización limitada exclusivamente al workload y recurso requerido.
Conceptualmente:
plaintextinvoice-service
│
▼
ServiceAccount
invoice-reader
│
▼
Workload Identity
│
▼
OCI IAM Policy
│
▼
finance-invoices bucket
La identidad queda relacionada con la aplicación y no con el worker node completo.
Esto mejora significativamente la granularidad.
GitHub Actions también puede utilizar OIDC con OKE
Oracle dispone además de un patrón específico para permitir que GitHub Actions acceda a clusters OKE mediante OpenID Connect.
El objetivo es eliminar la necesidad de credenciales de larga duración dentro del pipeline CI/CD.
En este escenario:
plaintext
GitHub Actions
│
│ OIDC
▼
OKE
│
▼
Kubernetes RBAC
Oracle documenta la posibilidad de habilitar GitHub como issuer OIDC y utilizar RBAC para limitar las operaciones permitidas dentro del cluster.
Esto es especialmente interesante porque podemos aplicar controles tanto en:
Cloud IAM
como en:
Kubernetes RBAC
Caso 3: agentes de Inteligencia Artificial
Aquí comienza una discusión todavía más interesante.
Los agentes de IA están dejando de ser solamente interfaces conversacionales.
Actualmente pueden ejecutar acciones como:
- Consultar datos
- Leer archivos
- Invocar APIs
- Ejecutar funciones
- Analizar logs
- Crear tickets
- Desplegar aplicaciones
- Modificar infraestructura
En otras palabras:
Un agente también es un workload.
Supongamos que tenemos un agente que debe analizar archivos guardados en OCI Object Storage.
Una implementación rápida podría ser:
`plaintext
AI Agent
│
▼
API Key guardada como secret
│
▼
Object Storage
`
Funciona.
Pero ahora el agente posee una credencial permanente.
Una arquitectura más interesante sería:
Oracle incluye explícitamente AI agents entre los workloads que pueden beneficiarse de este patrón cuando la plataforma de origen puede emitir una identidad verificable.
Por qué esto es especialmente importante para agentes autónomos
Un agente autónomo puede ejecutarse:
24x7
Puede iniciar cientos de tareas.
Puede interactuar con múltiples sistemas.
Por eso deberíamos evitar diseñar algo así:
`plaintext
AI Agent
+
Powerful permanent credential
+
Broad permissions
La alternativa debería acercarse a:
Verified workload identity
+
Short-lived session
+
Least privilege
+
Context-based authorization
`
La diferencia fundamental es que estamos desplazando el modelo desde:
administrar secretos
hacia:
- administrar confianza e identidad.
- Autenticación y autorización no son lo mismo
- Este punto es fundamental.
Workload Identity Federation responde principalmente a:
¿Quién está realizando la solicitud?
Pero después necesitamos responder:
¿Qué puede hacer?
La respuesta sigue siendo IAM.
Un workload autenticado correctamente no debería recibir automáticamente acceso total.
El flujo correcto es:
plaintext
Authentication
│
▼
Identity verified
│
▼
Authorization
│
▼
IAM Policy evaluation
│
▼
Resource access
Claims + IAM = autorización contextual
Supongamos que un token contiene:
repository = company/payment-api
branch = main
environment = production
Podemos imaginar una política donde solamente determinadas combinaciones sean aceptadas.
Por ejemplo:
plaintext
Repositorio correcto
+
Workflow correcto
+
Environment production
+
Recurso específico
El objetivo es evitar un patrón como:
plaintext
Any repository
↓
Any workflow
↓
Production resources
La identidad por sí sola no proporciona seguridad.
La seguridad aparece cuando diseñamos correctamente la relación entre:
Issuer
Claims
Trust
IAM Policies
Resource Scope
ABAC: Attribute-Based Access Control
Este modelo también abre una puerta interesante hacia Attribute-Based Access Control (ABAC).
En lugar de mantener cientos de usuarios técnicos:
service-user-001
service-user-002
service-user-003
service-user-004
...
podemos utilizar atributos provenientes de la identidad.
Ejemplo:
Repository
Namespace
ServiceAccount
Environment
Issuer
Workflow
y combinarlos con atributos del recurso.
Conceptualmente:
plaintext
Principal Attributes
+
Resource Attributes
+
IAM Policy
=
Authorization Decision
Oracle señala que ciertos claims provenientes del workload pueden propagarse y utilizarse en decisiones de IAM basadas en atributos.
Una arquitectura multicloud
Workload Identity Federation resulta particularmente interesante cuando OCI forma parte de una arquitectura multicloud.
Por ejemplo:
El mismo principio puede aplicarse a workloads provenientes de:
- AWS
- Azure
- Google Cloud
- GitHub
- Kubernetes
Oracle describe precisamente este modelo de confianza para workloads procedentes de otras plataformas cloud.
Beneficios arquitectónicos
Menos secretos
Menos API keys almacenadas implica menos elementos que:
- proteger;
- rotar;
- distribuir;
- revocar;
- auditar.
- Sesiones temporales Las credenciales efímeras reducen la ventana de exposición frente a una credencial permanente.
Identidad del workload
Podemos autorizar a:
payment-api
en lugar de autorizar genéricamente al:
worker-node-01
Mejor separación de responsabilidades
Un workload puede tener únicamente los permisos que necesita.
Ejemplo:
`plaintext
CI/CD workflow
→ Deploy Function
Application
→ Read Object Storage
AI Agent
→ Read specific bucket
Monitoring Agent
→ Read metrics
Cada identidad tiene un propósito.
`
Consideraciones de seguridad
Workload Identity Federation elimina algunas responsabilidades, pero no elimina la necesidad de diseñar seguridad.
Hay varios puntos que considero esenciales.
- Validar cuidadosamente el issuer
OCI debe confiar solamente en proveedores de identidad conocidos y controlados.
- Restringir los claims
No sería suficiente confiar únicamente en:
issuer = GitHub
Eso sería demasiado amplio.
Tiene más sentido evaluar:
organization
repository
workflow
branch
environment
- Aplicar mínimo privilegio
La federación no justifica políticas como:
manage all-resources in tenancy
Cada workload debería recibir únicamente las acciones que realmente necesita.
- Separar DEV, QA y PROD
Una estrategia saludable sería:
`plaintext
DEV identity
↓
DEV resources
QA identity
↓
QA resources
PROD identity
↓
PROD resources
`
No utilizar la misma autorización para todos los ambientes.
- Auditar
La autenticación machine-to-machine también debe formar parte de nuestra estrategia de observabilidad y auditoría.
Deberíamos ser capaces de responder preguntas como:
¿Qué workload accedió?
¿Cuándo?
¿Qué recurso utilizó?
¿Qué operación ejecutó?
¿Qué política permitió la operación?
En OKE, Oracle indica que las solicitudes realizadas mediante workload identities pueden rastrearse mediante OCI Audit.
¿Reemplaza completamente las API Keys?
No necesariamente.
Existen aplicaciones legacy, integraciones antiguas y escenarios particulares donde todavía pueden utilizarse credenciales tradicionales.
Pero para nuevos diseños de:
CI/CD
Kubernetes
Multicloud
Automation
AI Agents
Cloud-native workloads
vale la pena preguntarnos primero:
¿Realmente necesito crear otra credencial permanente?
Muchas veces la respuesta será no.
Mi regla de diseño
Cuando diseño acceso machine-to-machine intento seguir este orden:
¿Existe una identidad nativa del workload?
¿Podemos establecer confianza con esa identidad?
¿Podemos utilizar una credencial temporal?
¿Podemos limitar permisos mediante claims?
¿Podemos auditar completamente el acceso?
Solo si lo anterior no es posible:
considerar una credencial permanente.
Este pequeño cambio de mentalidad reduce considerablemente la dependencia de secretos.
Conclusión
Durante años, muchas arquitecturas cloud han utilizado el mismo patrón:
Para mí, la parte más interesante no es solamente eliminar API keys.
Es cambiar la unidad de confianza.
Ya no confiamos simplemente en una credencial que alguien posee.
Podemos confiar en la identidad verificable del workload que está ejecutando la operación.
En arquitecturas donde cada vez tenemos más pipelines, contenedores, automatizaciones y agentes de IA interactuando entre sí, ese cambio puede convertirse en una pieza importante para construir plataformas cloud más seguras y operables.
Autor: Jorge Luis Rodriguez Noriega
Tema: Oracle Cloud Infrastructure, IAM, DevOps, Kubernetes, AI Security
Top comments (0)