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

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: plaintext invoice-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 imagi