OCI permite federar identidades externas para no guardar claves permanentes en pipelines
La federación de identidad de cargas de trabajo de Oracle Cloud Infrastructure canjea tokens OIDC de GitHub o de Kubernetes por sesiones efímeras, sin API keys residentes.
Oracle Cloud Infrastructure permite que una carga de trabajo externa presente una identidad emitida por su plataforma de origen y la canjee por acceso temporal a OCI. El caso típico: un pipeline de GitHub Actions o un pod de Kubernetes que necesita tocar Object Storage durante unos minutos, sin llevar encima una clave de OCI. Oracle llama al resultado Resource Principal Session Token efímero (RPST).
Lo interesante no es el intercambio en sí, sino lo que desaparece: el usuario técnico permanente que durante años se creaba para cada workload y que sobrevivía mucho después de que ese workload dejara de existir.
El problema de la credencial que vive de más
El modelo clásico guarda OCI_USER_OCID, OCI_TENANCY_OCID, OCI_FINGERPRINT y OCI_PRIVATE_KEY en el almacén de secretos, y el pipeline funciona. El precio es todo lo que viene después: proteger esa clave privada, decidir quién puede leerla, rotarla, retirarla cuando ya no se usa y vigilar que no acabe dentro de una imagen de contenedor, un log o un cuaderno de trabajo. La pregunta que plantea Oracle es sencilla: por qué entregar una credencial permanente a algo que solo necesita acceso durante unos minutos.
En el esquema federado el workload conserva su identidad original. GitHub emite un token OIDC firmado que describe el workflow; Kubernetes usa el token de su ServiceAccount. OCI valida quién lo firma y emite una sesión corta, y una política de IAM decide a qué recursos llega.
Los claims como parte de la autorización
Aquí está el detalle que más cambia el diseño. Los tokens externos llevan claims, y OCI puede usarlos como contexto. De GitHub se puede leer la organización, el repositorio, el workflow, la rama o el environment; de Kubernetes, el cluster, el namespace y el ServiceAccount. La política deja de preguntar solo quién eres y pasa a preguntar de dónde vienes y en qué circunstancias. Un permiso puede quedar atado a un repositorio y a una rama concretos en lugar de a una identidad genérica.
Oracle lo resume en tres ideas: sin usuarios permanentes, sin credenciales permanentes y autorización basada en claims. La ganancia está en la operación diaria: menos altas de usuarios técnicos, menos revisiones periódicas, menos offboarding y menos secretos repartidos por configuraciones de CI/CD.
Lo que queda por ver es el coste de montaje. Hay que registrar el emisor externo, definir la confianza y escribir políticas que traduzcan los claims a permisos, y ahí la granularidad depende enteramente de cómo se emitan esos atributos. Un claim bien puesto acota el acceso a un workflow; uno mal puesto lo deja tan ancho como la clave que se quería eliminar.
