OCI Workload Identity Federation: acceso sin credenciales permanentes para GitHub Actions, Kubernetes y agentes de IA

Jorge Rodriguez Noriega — Sat, 19 Sep 2026 05:36:10 +0000

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

oracle #oci #cloud #devops #kubernetes #githubactions #iam #security #ai #cloudsecurity

DEV Community: Jorge Rodriguez Noriega

OCI Workload Identity Federation: acceso sin credenciales permanentes para GitHub Actions, Kubernetes y agentes de IA

oracle #oci #cloud #devops #kubernetes #githubactions #iam #security #ai #cloudsecurity