Project<\/strong><\/td>\n| Disponible para un solo proyecto<\/td>\n | Mejor aislamiento. T\u00fa controlas la m\u00e1quina, la configuraci\u00f3n de Docker y el acceso a la red.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nPaso 1 \u2014 Registrar un Runner Espec\u00edfico del Proyecto<\/h3>\nEn una m\u00e1quina que controles (una VM, un servidor disponible o incluso un host Docker local), instala GitLab Runner y reg\u00edstralo:<\/p>\n # Instalar GitLab Runner (Linux amd64)\nsudo curl -L --output \/usr\/local\/bin\/gitlab-runner \\\n https:\/\/gitlab-runner-downloads.s3.amazonaws.com\/latest\/binaries\/gitlab-runner-linux-amd64\nsudo chmod +x \/usr\/local\/bin\/gitlab-runner\nsudo gitlab-runner install --user=gitlab-runner --working-directory=\/home\/gitlab-runner\nsudo gitlab-runner start\n\n# Registrar el runner\n# Encuentra tu token de registro: Settings > CI\/CD > Runners > Expand > New project runner\nsudo gitlab-runner register \\\n --non-interactive \\\n --url https:\/\/gitlab.com\/ \\\n --token \"$RUNNER_TOKEN\" \\\n --executor docker \\\n --docker-image alpine:latest \\\n --description \"secure-deploy-runner\" \\\n --tag-list \"secure-deploy\" \\\n --access-level ref_protected\n<\/code><\/pre>\nEl indicador cr\u00edtico es --access-level ref_protected<\/code>. Esto le dice a GitLab que el runner solo aceptar\u00e1 trabajos de ramas o tags protegidos<\/strong>. Un pipeline activado por una rama de funcionalidad o un merge request de fork nunca se programar\u00e1 en este runner.<\/p>\nPaso 2 \u2014 Deshabilitar Runners Compartidos para Trabajos Sensibles<\/h3>\nVe a Settings > CI\/CD > Runners<\/strong> y cambia Enable shared runners for this project<\/strong> a desactivado \u2014 o d\u00e9jalos activados para stages no sensibles y usa tags para dirigir los trabajos sensibles a tu runner de proyecto.<\/p>\nPaso 3 \u2014 Actualizar el Pipeline con Selecci\u00f3n de Runner Basada en Tags<\/h3>\n# .gitlab-ci.yml \u2014 Ejercicio 2\nstages:\n - build\n - test\n - deploy\n\nbuild-job:\n stage: build\n # Se ejecuta en cualquier runner disponible (compartido est\u00e1 bien para builds)\n script:\n - echo \"Building the application...\"\n\ntest-job:\n stage: test\n script:\n - echo \"Running tests...\"\n\ndeploy-job:\n stage: deploy\n tags:\n - secure-deploy # Solo se ejecuta en runner(s) con este tag\n script:\n - echo \"Deploying with DEPLOY_TOKEN...\"\n - |\n curl --fail --silent --header \"PRIVATE-TOKEN: $DEPLOY_TOKEN\" \\\n https:\/\/gitlab.com\/api\/v4\/projects\/$CI_PROJECT_ID\/releases\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n<\/code><\/pre>\nDado que el runner secure-deploy<\/code> est\u00e1 registrado con acceso ref_protected<\/code>, este trabajo de despliegue solo se ejecutar\u00e1 en el runner espec\u00edfico del proyecto y<\/strong> solo cuando el pipeline se origine desde una referencia protegida.<\/p>\nEjercicio 3: Entornos Protegidos y Aprobaciones de Despliegue<\/h2>\nIncluso con variables protegidas y runners con alcance definido, es posible que desees una puerta humana antes de que el c\u00f3digo llegue a producci\u00f3n. Los entornos protegidos<\/strong> de GitLab proporcionan exactamente eso.<\/p>\nPaso 1 \u2014 Crear Entornos<\/h3>\n\n- Navega a Operate > Environments > New environment<\/strong>.<\/li>\n
- Crea dos entornos:
staging<\/code> y production<\/code>.<\/li>\n<\/ol>\nPaso 2 \u2014 Proteger el Entorno de Producci\u00f3n<\/h3>\n\n- Ve a Settings > CI\/CD > Protected environments<\/strong> (disponible en Premium\/Ultimate, o en el nivel gratuito auto-gestionado).<\/li>\n
- Selecciona
production<\/code>.<\/li>\n- En Allowed to deploy<\/strong>, restringe a
Maintainers<\/code> (o un usuario espec\u00edfico).<\/li>\n- En Required approvals<\/strong>, establece en 1<\/strong> (o m\u00e1s, dependiendo de tu pol\u00edtica).<\/li>\n
- Agrega el\/los aprobador(es) designado(s).<\/li>\n<\/ol>\n
Paso 3 \u2014 Actualizar el Pipeline con Definiciones de Entorno<\/h3>\n# .gitlab-ci.yml \u2014 Ejercicio 3\nstages:\n - build\n - test\n - deploy\n\nbuild-job:\n stage: build\n script:\n - echo \"Building the application...\"\n\ntest-job:\n stage: test\n script:\n - echo \"Running tests...\"\n\ndeploy-staging:\n stage: deploy\n environment:\n name: staging\n url: https:\/\/staging.example.com\n script:\n - echo \"Deploying to staging...\"\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy-production:\n stage: deploy\n tags:\n - secure-deploy\n environment:\n name: production\n url: https:\/\/prod.example.com\n script:\n - echo \"Deploying to production...\"\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n when: manual # Requiere un clic humano\n allow_failure: false # El pipeline permanece bloqueado hasta ser aprobado\n<\/code><\/pre>\nC\u00f3mo Funciona la Aprobaci\u00f3n<\/h3>\n\n- Un push a
main<\/code> activa el pipeline.<\/li>\ndeploy-staging<\/code> se ejecuta autom\u00e1ticamente.<\/li>\ndeploy-production<\/code> muestra un bot\u00f3n Play<\/strong> en la interfaz del pipeline.<\/li>\n- Hacer clic en Play<\/strong> no ejecuta inmediatamente el trabajo \u2014 GitLab verifica las reglas de protecci\u00f3n del entorno y presenta un di\u00e1logo de aprobaci\u00f3n<\/strong> al\/los aprobador(es) designado(s).<\/li>\n
- Solo despu\u00e9s de que se alcance el n\u00famero requerido de aprobaciones, el trabajo comienza.<\/li>\n<\/ol>\n
Esta puerta de dos capas \u2014 when: manual<\/code> m\u00e1s aprobaci\u00f3n de entorno \u2014 asegura que ninguna persona individual pueda enviar c\u00f3digo directamente a producci\u00f3n sin revisi\u00f3n.<\/p>\nEjercicio 4: Alcance de CI_JOB_TOKEN<\/h2>\nCada trabajo de GitLab CI recibe un token autom\u00e1tico en la variable CI_JOB_TOKEN<\/code>. Este token autentica solicitudes de API y Git como el proyecto del pipeline<\/em>. Por defecto, su alcance es peligrosamente amplio.<\/p>\nEl Riesgo<\/h3>\nSin restricciones, un trabajo en el Proyecto A puede usar CI_JOB_TOKEN<\/code> para clonar o llamar a la API de cualquier otro proyecto<\/em> en el mismo grupo (o instancia, dependiendo de la configuraci\u00f3n). Si un colaborador malicioso inyecta un script en un trabajo de CI, puede exfiltrar c\u00f3digo de repositorios no relacionados.<\/p>\nPaso 1 \u2014 Restringir el Alcance del Token<\/h3>\n\n- Ve a Settings > CI\/CD > Token Access<\/strong>.<\/li>\n
- Cambia Limit access to this project<\/strong> a Enabled<\/strong>.<\/li>\n
- En Allow CI job tokens from the following projects to access this project<\/strong>, agrega solo los proyectos que genuinamente necesitan acceso (un modelo de lista de permitidos).<\/li>\n
- En Limit CI_JOB_TOKEN access to the following projects<\/strong> (saliente), agrega solo los proyectos que tu pipeline necesita alcanzar.<\/li>\n<\/ol>\n
Paso 2 \u2014 Probar el Acceso<\/h3>\n# .gitlab-ci.yml \u2014 Ejercicio 4\nstages:\n - test\n\ntest-token-allowed:\n stage: test\n script:\n - echo \"Cloning an allowed project...\"\n - git clone https:\/\/gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com\/my-group\/allowed-project.git\n - echo \"Success \u2014 access permitted\"\n\ntest-token-denied:\n stage: test\n script:\n - echo \"Cloning a non-allowed project...\"\n - git clone https:\/\/gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com\/my-group\/restricted-project.git\n # Salida esperada: remote: HTTP Basic: Access denied\n # fatal: Authentication failed \u2014 403 Forbidden\n allow_failure: true\n<\/code><\/pre>\nPaso 3 \u2014 Verificar<\/h3>\n\n- Ejecuta el pipeline.
test-token-allowed<\/code> tiene \u00e9xito y clona el proyecto permitido.<\/li>\ntest-token-denied<\/code> falla con 403 Forbidden<\/strong> porque restricted-project<\/code> no est\u00e1 en la lista de permitidos.<\/li>\n<\/ol>\nLecci\u00f3n clave:<\/strong> Siempre restringe CI_JOB_TOKEN<\/code> al conjunto m\u00e1s peque\u00f1o de proyectos que tu pipeline realmente necesita. Trata el alcance predeterminado \u00ababierto\u00bb como una mala configuraci\u00f3n.<\/p>\nEjercicio 5: Seguridad de Pipelines de Merge Request<\/h2>\nLos pipelines de merge request (MR) se ejecutan cuando un colaborador abre o actualiza un merge request. Son esenciales para la calidad del c\u00f3digo \u2014 pero tambi\u00e9n pueden ser un vector de ataque si no se configuran cuidadosamente.<\/p>\n El Riesgo<\/h3>\nCuando un colaborador externo hace fork de tu proyecto y abre un MR, GitLab puede ejecutar un pipeline en ese MR. Si el pipeline tiene acceso a variables protegidas o runners privilegiados, el c\u00f3digo del colaborador podr\u00eda exfiltrar secretos.<\/p>\n Paso 1 \u2014 Configurar Reglas de Pipeline de MR<\/h3>\n# .gitlab-ci.yml \u2014 Ejercicio 5\nstages:\n - validate\n - build\n - deploy\n\n# --- Trabajos seguros para ejecutar en pipelines de MR (no se necesitan secretos) ---\nlint:\n stage: validate\n script:\n - echo \"Linting code...\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nunit-tests:\n stage: validate\n script:\n - echo \"Running unit tests...\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\n# --- Trabajos que requieren secretos \u2014 nunca ejecutar en pipelines de MR ---\nbuild-image:\n stage: build\n script:\n - echo \"Building and pushing Docker image...\"\n - echo \"Using REGISTRY_TOKEN = $REGISTRY_TOKEN\" # Protected + Masked\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy-production:\n stage: deploy\n tags:\n - secure-deploy\n environment:\n name: production\n url: https:\/\/prod.example.com\n script:\n - echo \"Deploying to production...\"\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n when: manual\n<\/code><\/pre>\nC\u00f3mo GitLab Maneja los Pipelines de MR desde Forks<\/h3>\n\n- Los pipelines activados por
merge_request_event<\/code> desde un fork<\/strong> se ejecutan autom\u00e1ticamente con permisos limitados<\/strong>.<\/li>\n- Las variables protegidas nunca<\/strong> se inyectan en pipelines de MR desde forks.<\/li>\n
CI_JOB_TOKEN<\/code> en pipelines de fork tiene un alcance reducido \u2014 solo puede acceder al proyecto fuente (fork), no al destino.<\/li>\n<\/ul>\nAl separar tus trabajos en \u00abseguros para MR\u00bb (lint, test) y \u00abrequieren secretos\u00bb (build, deploy), aseguras que los colaboradores puedan validar su c\u00f3digo sin exponer credenciales.<\/p>\n Mejores Pr\u00e1cticas para Pipelines de MR<\/h3>\n\n- Nunca uses
only\/except<\/code> \u2014 prefiere rules:<\/code> para claridad y correcci\u00f3n.<\/li>\n- Controla los trabajos dependientes de secretos con
if: $CI_COMMIT_BRANCH == \"main\"<\/code> (u otra referencia protegida).<\/li>\n- Considera habilitar Pipelines must succeed<\/strong> en Settings > Merge requests<\/strong> para requerir que el pipeline de MR pase antes de fusionar.<\/li>\n
- Habilita Merged results pipelines<\/strong> para probar el resultado de la fusi\u00f3n<\/em> en lugar de solo la rama fuente \u2014 esto detecta problemas de integraci\u00f3n m\u00e1s temprano.<\/li>\n<\/ul>\n
Ejercicio 6: Endurecimiento Adicional<\/h2>\nCon variables, runners, entornos, tokens y pipelines de MR asegurados, varios controles adicionales llevan tu pipeline a una postura de seguridad de nivel producci\u00f3n.<\/p>\n Tiempos de Espera de Trabajos<\/h3>\nLos trabajos sin l\u00edmite pueden ser abusados para criptominer\u00eda o usados para mantener acceso persistente. Establece tiempos de espera expl\u00edcitos:<\/p>\n deploy-production:\n stage: deploy\n timeout: 10 minutes\n script:\n - echo \"Deploying...\"\n<\/code><\/pre>\nPipelines Interrumpibles<\/h3>\nPrev\u00e9n el desperdicio de recursos y limita la ventana para trabajos maliciosos de larga duraci\u00f3n marcando los trabajos no cr\u00edticos como interrumpibles:<\/p>\n lint:\n stage: validate\n interruptible: true # Se cancela autom\u00e1ticamente si un pipeline m\u00e1s nuevo comienza\n script:\n - echo \"Linting...\"\n<\/code><\/pre>\nPush Rules (Restringir la Creaci\u00f3n de Pipelines)<\/h3>\nEn Settings > Repository > Push rules<\/strong>, puedes:<\/p>\n\n- Rechazar commits sin firmar<\/strong> \u2014 asegura que cada commit est\u00e9 firmado con GPG.<\/li>\n
- Restringir nombres de ramas<\/strong> \u2014 aplicar una convenci\u00f3n de nombres (por ejemplo,
feature\/*<\/code>, bugfix\/*<\/code>).<\/li>\n- Prevenir el push de secretos<\/strong> \u2014 la regla de push integrada de GitLab puede bloquear archivos que coincidan con patrones comunes de secretos.<\/li>\n<\/ul>\n
Detecci\u00f3n de Secretos con GitLab SAST<\/h3>\nAgrega la plantilla integrada de Detecci\u00f3n de Secretos de GitLab para capturar credenciales accidentalmente comprometidas:<\/p>\n
|