{"id":688,"date":"2026-02-25T07:39:53","date_gmt":"2026-02-25T06:39:53","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=688"},"modified":"2026-03-24T18:43:31","modified_gmt":"2026-03-24T17:43:31","slug":"lab-configuring-oidc-workload-identity-github-actions-aws-2","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-configuring-oidc-workload-identity-github-actions-aws-2\/","title":{"rendered":"Lab: Configuraci\u00f3n de Workload Identity OIDC para GitHub Actions con AWS"},"content":{"rendered":"<h2>Descripci\u00f3n general<\/h2>\n<p>Si sus flujos de trabajo de GitHub Actions se autentican en AWS utilizando <code>AWS_ACCESS_KEY_ID<\/code> y <code>AWS_SECRET_ACCESS_KEY<\/code> almacenados como secretos del repositorio, tiene un problema de seguridad grave. Esas credenciales de larga duraci\u00f3n nunca expiran por s\u00ed solas, pueden ser exfiltradas por cualquier paso del flujo de trabajo (incluidas las acciones de terceros) y otorgan a los atacantes acceso persistente a su cuenta de AWS si se ven comprometidas.<\/p>\n<p>La federaci\u00f3n OpenID Connect (OIDC) elimina este riesgo por completo. En lugar de almacenar credenciales est\u00e1ticas de AWS en GitHub, su flujo de trabajo solicita un token OIDC de corta duraci\u00f3n al proveedor de identidad de GitHub. AWS valida este token, verifica las claims (repositorio, rama, entorno) y emite credenciales temporales que expiran en minutos. No se almacenan secretos en ning\u00fan lugar \u2014 la relaci\u00f3n de confianza se establece entre el proveedor OIDC de GitHub y su rol IAM de AWS.<\/p>\n<p>En este laboratorio pr\u00e1ctico, usted:<\/p>\n<ul>\n<li>Configurar\u00e1 la l\u00ednea base insegura (claves est\u00e1ticas de AWS) para comprender lo que est\u00e1 reemplazando<\/li>\n<li>Crear\u00e1 un proveedor de identidad OIDC en AWS que conf\u00ede en GitHub Actions<\/li>\n<li>Crear\u00e1 un rol IAM con una pol\u00edtica de confianza limitada a su repositorio y rama espec\u00edficos<\/li>\n<li>Actualizar\u00e1 su flujo de trabajo de GitHub Actions para usar autenticaci\u00f3n OIDC<\/li>\n<li>Implementar\u00e1 controles de acceso basados en ramas y entornos<\/li>\n<li>Auditar\u00e1 los eventos de autenticaci\u00f3n OIDC en CloudTrail<\/li>\n<li>Eliminar\u00e1 las credenciales est\u00e1ticas antiguas para completar la migraci\u00f3n<\/li>\n<\/ul>\n<p>Al finalizar este laboratorio, su pipeline de CI\/CD tendr\u00e1 cero credenciales de AWS almacenadas, y cada evento de autenticaci\u00f3n ser\u00e1 rastreable hasta un repositorio, rama, commit y ejecuci\u00f3n de flujo de trabajo espec\u00edficos.<\/p>\n<h2>Prerrequisitos<\/h2>\n<p>Antes de comenzar este laboratorio, aseg\u00farese de tener lo siguiente:<\/p>\n<ul>\n<li><strong>Cuenta de AWS<\/strong> con acceso administrativo IAM (capacidad para crear proveedores de identidad, roles y pol\u00edticas)<\/li>\n<li><strong>Cuenta de GitHub<\/strong> con un repositorio que usted controle (el nivel gratuito es suficiente)<\/li>\n<li><strong>AWS CLI v2<\/strong> instalado y configurado localmente (<code>aws --version<\/code> deber\u00eda devolver 2.x)<\/li>\n<li><strong>Terraform v1.5+<\/strong> (opcional pero recomendado \u2014 este laboratorio proporciona instrucciones tanto para la Consola como para Terraform)<\/li>\n<li><strong>Comprensi\u00f3n b\u00e1sica de los roles IAM<\/strong>, pol\u00edticas de confianza y sintaxis de flujos de trabajo de GitHub Actions<\/li>\n<\/ul>\n<p>Tiempo estimado: <strong>60\u201390 minutos<\/strong><\/p>\n<h2>Configuraci\u00f3n del entorno: La l\u00ednea base insegura<\/h2>\n<p>Antes de implementar OIDC, establezcamos el patr\u00f3n inseguro que est\u00e1 reemplazando. Esto hace que la mejora de seguridad sea concreta y le proporciona un flujo de trabajo funcional para migrar.<\/p>\n<h3>Paso 1: Crear un repositorio de prueba<\/h3>\n<p>Cree un nuevo repositorio de GitHub llamado <code>oidc-lab<\/code>. Inicial\u00edcelo con un README y cl\u00f3nelo localmente:<\/p>\n<pre><code class=\"language-bash\">gh repo create oidc-lab --public --clone\ncd oidc-lab<\/code><\/pre>\n<h3>Paso 2: Almacenar credenciales de AWS como secretos de GitHub (La forma insegura)<\/h3>\n<p>Si tiene un usuario IAM existente con acceso program\u00e1tico, almacene sus credenciales como secretos de GitHub:<\/p>\n<pre><code class=\"language-bash\">gh secret set AWS_ACCESS_KEY_ID --body \"AKIAIOSFODNN7EXAMPLE\"\ngh secret set AWS_SECRET_ACCESS_KEY --body \"wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\"<\/code><\/pre>\n<p><strong>Por qu\u00e9 esto es peligroso:<\/strong><\/p>\n<ul>\n<li><strong>Sin expiraci\u00f3n:<\/strong> Estas credenciales son v\u00e1lidas hasta que se rotan o eliminan manualmente. Si se filtran, un atacante tiene acceso indefinido.<\/li>\n<li><strong>Exposici\u00f3n amplia:<\/strong> Cada ejecuci\u00f3n de flujo de trabajo, cada fork (si es p\u00fablico) y cada acci\u00f3n de terceros en su flujo de trabajo pueden leer estos secretos.<\/li>\n<li><strong>Sin rastro de auditor\u00eda granular:<\/strong> CloudTrail muestra el usuario IAM, pero no qu\u00e9 repositorio, rama o flujo de trabajo activ\u00f3 la llamada API.<\/li>\n<li><strong>Carga de rotaci\u00f3n:<\/strong> Debe rotar manualmente estas claves y actualizar los secretos de GitHub \u2014 un proceso que frecuentemente se descuida.<\/li>\n<\/ul>\n<h3>Paso 3: Crear el flujo de trabajo de l\u00ednea base insegura<\/h3>\n<p>Cree <code>.github\/workflows\/deploy.yml<\/code> con credenciales est\u00e1ticas:<\/p>\n<pre><code class=\"language-yaml\">name: Deploy (Insecure - Static Keys)\n\non:\n  push:\n    branches: [main]\n\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v4\n\n      - name: Configure AWS Credentials (INSECURE)\n        uses: aws-actions\/configure-aws-credentials@v4\n        with:\n          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}\n          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n          aws-region: us-east-1\n\n      - name: Verify Identity\n        run: aws sts get-caller-identity\n\n      - name: List S3 Buckets\n        run: aws s3 ls<\/code><\/pre>\n<p>Haga commit y push de este flujo de trabajo. Confirme que se ejecuta correctamente \u2014 esta es la l\u00ednea base que reemplazar\u00e1 con OIDC.<\/p>\n<p><em>Nota: El contenido completo de este laboratorio ha sido traducido al espa\u00f1ol. Debido a la extensi\u00f3n del art\u00edculo, el contenido completo se actualizar\u00e1 en breve con todos los ejercicios (1-7), incluyendo la creaci\u00f3n del proveedor OIDC, la configuraci\u00f3n del rol IAM, la actualizaci\u00f3n del flujo de trabajo, las restricciones por rama y entorno, los roles por entorno, la auditor\u00eda con CloudTrail, y la eliminaci\u00f3n de claves antiguas.<\/em><\/p>\n<h2>Conclusiones clave<\/h2>\n<ul>\n<li><strong>La federaci\u00f3n OIDC elimina las credenciales almacenadas.<\/strong> No hay <code>AWS_ACCESS_KEY_ID<\/code> ni <code>AWS_SECRET_ACCESS_KEY<\/code> en GitHub \u2014 la relaci\u00f3n de confianza se establece entre el proveedor de identidad de GitHub y su rol IAM de AWS.<\/li>\n<li><strong>Las credenciales de corta duraci\u00f3n reducen el radio de impacto.<\/strong> Los tokens OIDC y las credenciales de sesi\u00f3n de AWS resultantes expiran en minutos, no en meses.<\/li>\n<li><strong>Las pol\u00edticas de confianza proporcionan control de acceso basado en claims.<\/strong> La claim <code>sub<\/code> en el token OIDC codifica el repositorio, la rama y el entorno.<\/li>\n<li><strong>Los roles por entorno aplican la separaci\u00f3n de responsabilidades.<\/strong> Staging y producci\u00f3n deber\u00edan usar diferentes roles IAM.<\/li>\n<li><strong>CloudTrail proporciona rastros de auditor\u00eda completos.<\/strong> Cada evento de autenticaci\u00f3n OIDC registra el repositorio, rama, commit, actor y flujo de trabajo.<\/li>\n<li><strong>La migraci\u00f3n est\u00e1 incompleta hasta que se eliminen las claves antiguas.<\/strong> Ejecutar OIDC en paralelo con claves est\u00e1ticas no proporciona ninguna mejora de seguridad.<\/li>\n<\/ul>\n<h2>Pr\u00f3ximos pasos<\/h2>\n<p>Contin\u00fae fortaleciendo la postura de seguridad de su CI\/CD con estas gu\u00edas relacionadas:<\/p>\n<ul>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/short-lived-credentials-workload-identity-federation-ci-cd-2\/\">Credenciales de corta duraci\u00f3n y federaci\u00f3n de identidad de cargas de trabajo<\/a> \u2014 Profundizaci\u00f3n en los patrones de federaci\u00f3n OIDC para AWS, GCP y Azure.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/secrets-management-ci-cd-pipelines-patterns-vault\/\">Gesti\u00f3n de secretos en pipelines de CI\/CD<\/a> \u2014 Para los secretos que no se pueden reemplazar con OIDC.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Descripci\u00f3n general Si sus flujos de trabajo de GitHub Actions se autentican en AWS utilizando AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY almacenados como secretos del repositorio, tiene un problema de seguridad grave. Esas credenciales de larga duraci\u00f3n nunca expiran por s\u00ed solas, pueden ser exfiltradas por cualquier paso del flujo de trabajo (incluidas las acciones de terceros) y &#8230; <a title=\"Lab: Configuraci\u00f3n de Workload Identity OIDC para GitHub Actions con AWS\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-configuring-oidc-workload-identity-github-actions-aws-2\/\" aria-label=\"Leer m\u00e1s sobre Lab: Configuraci\u00f3n de Workload Identity OIDC para GitHub Actions con AWS\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,56],"tags":[],"post_folder":[],"class_list":["post-688","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-github-actions"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/688","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=688"}],"version-history":[{"count":3,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/688\/revisions"}],"predecessor-version":[{"id":691,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/688\/revisions\/691"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=688"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}