{"id":610,"date":"2026-01-23T23:09:03","date_gmt":"2026-01-23T22:09:03","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=610"},"modified":"2026-03-25T08:36:43","modified_gmt":"2026-03-25T07:36:43","slug":"gitlab-ci-security-cheat-sheet","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/gitlab-ci-security-cheat-sheet\/","title":{"rendered":"Cheat Sheet de Seguridad de GitLab CI: Variables, Runners, Entornos y OIDC"},"content":{"rendered":"<h2>Por Qu\u00e9 Importa la Seguridad en GitLab CI<\/h2>\n<p>Los pipelines de GitLab CI\/CD son potentes \u2014 pero con ese poder viene el riesgo. Una variable mal configurada puede filtrar secretos. Un runner sin alcance definido puede ejecutar c\u00f3digo malicioso. Un entorno sin protecci\u00f3n puede permitir que un desarrollador junior haga un despliegue directo a producci\u00f3n. Este cheat sheet te ofrece <strong>YAML listo para copiar y pegar<\/strong> para cada control cr\u00edtico de seguridad en GitLab CI, desde variables protegidas hasta la federaci\u00f3n OIDC.<\/p>\n<p>Guarda esta p\u00e1gina en tus favoritos. \u00dasala como referencia cada vez que configures un nuevo proyecto o audites uno existente.<\/p>\n<h2>1. Variables Protegidas, Enmascaradas y Ocultas<\/h2>\n<p>Las variables de GitLab CI\/CD controlan c\u00f3mo fluyen los secretos en tus pipelines. Configurar esto incorrectamente es la causa n\u00famero uno de fugas de credenciales en CI\/CD. Cada valor sensible debe estar <strong>protegido<\/strong> (disponible solo en ramas\/tags protegidos), <strong>enmascarado<\/strong> (oculto en los logs del job) y, donde sea compatible, <strong>oculto<\/strong> (invisible en la interfaz despu\u00e9s de la creaci\u00f3n).<\/p>\n<h3>Configuraci\u00f3n de Variables a trav\u00e9s de la API<\/h3>\n<pre><code># Crear una variable protegida + enmascarada a trav\u00e9s de la API de GitLab\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/variables\" \\\n  --form \"key=AWS_SECRET_ACCESS_KEY\" \\\n  --form \"value=$MY_SECRET\" \\\n  --form \"protected=true\" \\\n  --form \"masked=true\" \\\n  --form \"variable_type=env_var\"<\/code><\/pre>\n<h3>Uso de Variables en <code>.gitlab-ci.yml<\/code><\/h3>\n<pre><code>variables:\n  # Las variables a nivel de grupo o proyecto se inyectan autom\u00e1ticamente.\n  # Las variables de tipo archivo se escriben en una ruta temporal.\n  DEPLOY_TOKEN:\n    description: \"Token para despliegue en producci\u00f3n\"\n    value: \"\"  # Intencionalmente vac\u00edo \u2014 configurar en CI\/CD Settings\n\ndeploy_production:\n  stage: deploy\n  script:\n    - echo \"Desplegando con token enmascarado...\"\n    - .\/deploy.sh --token \"$DEPLOY_TOKEN\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>Reglas clave:<\/strong><\/p>\n<ul>\n<li>Nunca escribas secretos directamente en <code>.gitlab-ci.yml<\/code> \u2014 utiliza siempre la configuraci\u00f3n de variables CI\/CD.<\/li>\n<li>Establece <code>protected=true<\/code> para que los secretos solo est\u00e9n disponibles en ramas protegidas.<\/li>\n<li>Establece <code>masked=true<\/code> para que los valores se oculten en los logs del job.<\/li>\n<li>Usa <strong>variables a nivel de grupo<\/strong> para secretos compartidos entre proyectos (por ejemplo, credenciales de la nube).<\/li>\n<\/ul>\n<h2>2. Tipos de Runners y Alcance<\/h2>\n<p>Los runners ejecutan tus jobs de CI\/CD. Si cualquier runner puede tomar cualquier job, un merge request malicioso podr\u00eda exfiltrar secretos de un runner de producci\u00f3n. Un alcance adecuado es esencial.<\/p>\n<h3>Registro de Runner con Tags y Protecci\u00f3n<\/h3>\n<pre><code># Registrar un runner con alcance solo para ramas protegidas\ngitlab-runner register \\\n  --non-interactive \\\n  --url \"https:\/\/gitlab.example.com\" \\\n  --token \"$RUNNER_REG_TOKEN\" \\\n  --executor docker \\\n  --docker-image alpine:latest \\\n  --tag-list \"production,protected\" \\\n  --access-level ref_protected<\/code><\/pre>\n<h3>Asignaci\u00f3n de Jobs a Runners Espec\u00edficos<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 asegurar que los jobs de producci\u00f3n solo se ejecuten en runners protegidos\ndeploy_production:\n  stage: deploy\n  tags:\n    - production\n    - protected\n  script:\n    - kubectl apply -f k8s\/production\/\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production\n\n# Los jobs de desarrollo usan un runner separado y sin privilegios\ntest:\n  stage: test\n  tags:\n    - shared\n    - development\n  script:\n    - pytest tests\/<\/code><\/pre>\n<p><strong>Mejores pr\u00e1cticas:<\/strong><\/p>\n<ul>\n<li>Usa <code>--access-level ref_protected<\/code> para restringir los runners a ramas y tags protegidos.<\/li>\n<li>Usa <strong>runners espec\u00edficos del proyecto<\/strong> para cargas de trabajo sensibles \u2014 nunca compartas runners de producci\u00f3n entre proyectos no relacionados.<\/li>\n<li>Prefiere <strong>runners ef\u00edmeros<\/strong> (ejecutores Docker, Kubernetes) para que el entorno se destruya despu\u00e9s de cada job.<\/li>\n<li>Desactiva los shared runners en proyectos que manejan despliegues sensibles.<\/li>\n<\/ul>\n<h2>3. Entornos Protegidos con Aprobaciones<\/h2>\n<p>Los entornos protegidos a\u00f1aden una puerta humana antes de los despliegues. Esta es tu \u00faltima l\u00ednea de defensa contra cambios no autorizados en producci\u00f3n.<\/p>\n<h3>Configuraci\u00f3n del Entorno en <code>.gitlab-ci.yml<\/code><\/h3>\n<pre><code># .gitlab-ci.yml \u2014 despliegue con protecci\u00f3n de entorno\ndeploy_staging:\n  stage: deploy\n  script:\n    - .\/deploy.sh staging\n  environment:\n    name: staging\n    url: https:\/\/staging.example.com\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy_production:\n  stage: deploy\n  script:\n    - .\/deploy.sh production\n  environment:\n    name: production\n    url: https:\/\/example.com\n    deployment_tier: production\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n      allow_failure: false<\/code><\/pre>\n<h3>Configuraci\u00f3n de Reglas de Aprobaci\u00f3n a trav\u00e9s de la API<\/h3>\n<pre><code># Proteger el entorno de producci\u00f3n con aprobaciones requeridas\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/protected_environments\" \\\n  --data '{\"name\": \"production\", \"deploy_access_levels\": [{\"group_id\": 9899826}], \"required_approval_count\": 2, \"approval_rules\": [{\"group_id\": 9899826, \"required_approvals\": 2}]}'<\/code><\/pre>\n<p>Configura esto en <strong>Settings &gt; CI\/CD &gt; Protected Environments<\/strong> en la interfaz de GitLab. Requiere al menos <strong>dos aprobaciones<\/strong> para despliegues a producci\u00f3n. Restringe el acceso de despliegue a grupos o usuarios espec\u00edficos \u2014 nunca a &#8220;All maintainers.&#8221;<\/p>\n<h2>4. Alcance de CI_JOB_TOKEN<\/h2>\n<p><code>CI_JOB_TOKEN<\/code> es un token autom\u00e1tico que GitLab inyecta en cada job. Por defecto, puede acceder a otros proyectos en tu grupo \u2014 un riesgo serio de movimiento lateral. Desde GitLab 16.0, deber\u00edas restringir su alcance.<\/p>\n<h3>Restricci\u00f3n del Acceso del Token<\/h3>\n<pre><code># Verificar el alcance actual de CI_JOB_TOKEN\ncurl --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\"\n\n# Limitar CI_JOB_TOKEN para que solo acceda a proyectos espec\u00edficos\ncurl --request PATCH \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\" \\\n  --data '{\"enabled\": true}'\n\n# A\u00f1adir un proyecto a la lista de permitidos\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\/allowlist\" \\\n  --data '{\"target_project_id\": 12345}'<\/code><\/pre>\n<h3>Uso Seguro de <code>CI_JOB_TOKEN<\/code> en Pipelines<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 uso de CI_JOB_TOKEN para triggers entre proyectos\ntrigger_deploy:\n  stage: deploy\n  trigger:\n    project: my-group\/deploy-project\n    branch: main\n    strategy: depend\n  # CI_JOB_TOKEN se usa autom\u00e1ticamente para el trigger.\n  # El proyecto destino debe incluir este proyecto en su lista de permitidos.<\/code><\/pre>\n<p><strong>Reglas clave:<\/strong> Habilita el l\u00edmite de alcance del CI\/CD job token en cada proyecto. Solo incluye en la lista de permitidos los proyectos espec\u00edficos que genuinamente necesitan acceso entre proyectos. Audita las listas de permitidos trimestralmente.<\/p>\n<h2>5. OIDC <code>id_tokens<\/code> para AWS y GCP<\/h2>\n<p>La federaci\u00f3n OIDC elimina por completo las credenciales de nube de larga duraci\u00f3n en tus variables de CI\/CD. GitLab emite un JWT de corta duraci\u00f3n, y tu proveedor de nube lo intercambia por credenciales temporales. Este es el est\u00e1ndar de oro para la autenticaci\u00f3n en la nube en pipelines.<\/p>\n<h3>Federaci\u00f3n OIDC con AWS<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 autenticaci\u00f3n OIDC con AWS\ndeploy_aws:\n  stage: deploy\n  image: amazon\/aws-cli:latest\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https:\/\/gitlab.example.com\n  variables:\n    ROLE_ARN: arn:aws:iam::123456789012:role\/gitlab-ci-deploy\n  script:\n    - &gt;\n      export $(printf \"AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s\"\n      $(aws sts assume-role-with-web-identity\n      --role-arn $ROLE_ARN\n      --role-session-name \"GitLabCI-${CI_PROJECT_ID}-${CI_PIPELINE_ID}\"\n      --web-identity-token \"$GITLAB_OIDC_TOKEN\"\n      --duration-seconds 3600\n      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'\n      --output text))\n    - aws s3 sync .\/build s3:\/\/my-production-bucket\/\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<h3>Federaci\u00f3n de Identidades de Carga de Trabajo con GCP<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 autenticaci\u00f3n OIDC con GCP\ndeploy_gcp:\n  stage: deploy\n  image: google\/cloud-sdk:latest\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https:\/\/gitlab.example.com\n  script:\n    - echo \"$GITLAB_OIDC_TOKEN\" &gt; \/tmp\/gitlab_token.txt\n    - &gt;\n      gcloud iam workload-identity-pools create-cred-config\n      projects\/$GCP_PROJECT_NUMBER\/locations\/global\/workloadIdentityPools\/$POOL_ID\/providers\/$PROVIDER_ID\n      --service-account=\"$GCP_SERVICE_ACCOUNT\"\n      --output-file=\/tmp\/gcp_creds.json\n      --credential-source-file=\/tmp\/gitlab_token.txt\n    - export GOOGLE_APPLICATION_CREDENTIALS=\/tmp\/gcp_creds.json\n    - gcloud config set project $GCP_PROJECT_ID\n    - gcloud run deploy my-service --image gcr.io\/$GCP_PROJECT_ID\/my-app:$CI_COMMIT_SHA\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p>En el lado de la nube, configura la pol\u00edtica de confianza para validar claims como <code>project_path<\/code>, <code>ref<\/code> y <code>ref_protected<\/code> de modo que solo proyectos y ramas espec\u00edficos puedan asumir el rol.<\/p>\n<h2>6. Seguridad de Pipelines de Merge Request<\/h2>\n<p>Los pipelines de merge request se ejecutan sobre c\u00f3digo que a\u00fan no ha sido revisado. Tr\u00e1talos como no confiables. Nunca expongas secretos de producci\u00f3n a los pipelines de MR.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 reglas separadas para pipelines de MR vs. pipelines de rama\ntest:\n  stage: test\n  script:\n    - pytest tests\/\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy_production:\n  stage: deploy\n  script:\n    - .\/deploy.sh production\n  rules:\n    # NUNCA ejecutar en pipelines de merge request\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n      when: never\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>Controles cr\u00edticos:<\/strong><\/p>\n<ul>\n<li>Usa <code>rules:<\/code> para asegurar que los jobs de despliegue <strong>nunca<\/strong> se ejecuten en pipelines de tipo <code>merge_request_event<\/code>.<\/li>\n<li>Requiere <strong>que el pipeline sea exitoso<\/strong> antes de hacer merge (Settings &gt; Merge Requests).<\/li>\n<li>Habilita <strong>&#8220;Pipelines must succeed&#8221;<\/strong> y <strong>&#8220;All discussions must be resolved.&#8221;<\/strong><\/li>\n<li>Considera habilitar <strong>merged results pipelines<\/strong> para probar el estado post-merge.<\/li>\n<\/ul>\n<h2>7. Plantilla de Detecci\u00f3n de Secretos<\/h2>\n<p>El esc\u00e1ner integrado de detecci\u00f3n de secretos de GitLab captura credenciales accidentalmente comprometidas antes de que lleguen a la rama por defecto.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 incluir la plantilla de detecci\u00f3n de secretos\ninclude:\n  - template: Jobs\/Secret-Detection.gitlab-ci.yml\n\n# Sobrescribir para que el pipeline falle si se encuentran secretos\nsecret_detection:\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"  # Escanear el historial completo de git\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n  allow_failure: false  # Bloquear el pipeline al detectar secretos<\/code><\/pre>\n<p>Para un escaneo m\u00e1s completo, a\u00f1ade tambi\u00e9n las plantillas de <strong>SAST<\/strong> y <strong>dependency scanning<\/strong>:<\/p>\n<pre><code>include:\n  - template: Jobs\/Secret-Detection.gitlab-ci.yml\n  - template: Jobs\/SAST.gitlab-ci.yml\n  - template: Jobs\/Dependency-Scanning.gitlab-ci.yml<\/code><\/pre>\n<p>Revisa los hallazgos en el <strong>Security Dashboard<\/strong> (disponible en GitLab Ultimate) o analiza los artefactos JSON en los tiers inferiores.<\/p>\n<h2>8. Push Rules<\/h2>\n<p>Las push rules aplican pol\u00edticas a nivel de Git \u2014 antes de que el c\u00f3digo entre siquiera en un pipeline. \u00dasalas para prevenir que se suban secretos, imponer est\u00e1ndares en los mensajes de commit y restringir tipos de archivos.<\/p>\n<pre><code># Configurar push rules a trav\u00e9s de la API\ncurl --request PUT \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/push_rule\" \\\n  --data '{\"deny_delete_tag\": true, \"prevent_secrets\": true, \"commit_message_regex\": \"^(feat|fix|chore|docs|refactor|test|ci)\\\\(.*\\\\):.*\", \"max_file_size\": 50, \"member_check\": true, \"reject_unsigned_commits\": true}'<\/code><\/pre>\n<p><strong>Push rules recomendadas:<\/strong><\/p>\n<ul>\n<li><code>prevent_secrets: true<\/code> \u2014 Rechaza pushes que contengan archivos que parezcan secretos (claves, tokens, certificados).<\/li>\n<li><code>reject_unsigned_commits: true<\/code> \u2014 Requiere commits firmados con GPG (GitLab Premium+).<\/li>\n<li><code>commit_message_regex<\/code> \u2014 Impone mensajes de commit convencionales para un registro de auditor\u00eda limpio.<\/li>\n<li><code>max_file_size<\/code> \u2014 Previene la subida accidental de binarios grandes.<\/li>\n<li><code>member_check: true<\/code> \u2014 Rechaza commits de personas que no son miembros del proyecto.<\/li>\n<\/ul>\n<h2>9. Timeouts de Jobs e <code>interruptible<\/code><\/h2>\n<p>Los jobs desbocados desperdician recursos y pueden ser explotados para criptominer\u00eda. Establece timeouts expl\u00edcitos y marca los jobs no cr\u00edticos como interruptible para que se cancelen cuando un nuevo pipeline comience en la misma rama.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 timeouts e interruptible\ndefault:\n  timeout: 30m          # Timeout global por defecto para todos los jobs\n  interruptible: true   # Cancelar jobs en ejecuci\u00f3n cuando se hace push de un nuevo commit\n  retry:\n    max: 1\n    when:\n      - runner_system_failure\n      - stuck_or_timeout_failure\n\ntest:\n  stage: test\n  timeout: 15m\n  interruptible: true\n  script:\n    - pytest tests\/ --timeout=600\n\ndeploy_production:\n  stage: deploy\n  timeout: 20m\n  interruptible: false  # NUNCA cancelar un despliegue a producci\u00f3n en ejecuci\u00f3n\n  script:\n    - .\/deploy.sh production\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>Directrices:<\/strong><\/p>\n<ul>\n<li>Establece un <strong>timeout a nivel de proyecto<\/strong> en Settings &gt; CI\/CD &gt; General Pipelines (recomendado: 60 minutos m\u00e1ximo).<\/li>\n<li>Establece <strong>timeouts a nivel de job<\/strong> m\u00e1s ajustados que el valor por defecto del proyecto.<\/li>\n<li>Marca los jobs de test y lint como <code>interruptible: true<\/code> para ahorrar capacidad de runners.<\/li>\n<li>Marca los jobs de despliegue como <code>interruptible: false<\/code> para prevenir despliegues parciales.<\/li>\n<li>Usa <code>retry<\/code> solo para fallos transitorios de infraestructura \u2014 nunca para fallos de tests.<\/li>\n<\/ul>\n<h2>Tabla de Referencia R\u00e1pida<\/h2>\n<table>\n<thead>\n<tr>\n<th>Control<\/th>\n<th>D\u00f3nde Configurar<\/th>\n<th>Tier M\u00ednimo<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Variables Protegidas\/Enmascaradas<\/td>\n<td>Settings &gt; CI\/CD &gt; Variables<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>Alcance de Runners<\/td>\n<td>Settings &gt; CI\/CD &gt; Runners<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>Entornos Protegidos<\/td>\n<td>Settings &gt; CI\/CD &gt; Protected Environments<\/td>\n<td>Premium<\/td>\n<\/tr>\n<tr>\n<td>Alcance de CI_JOB_TOKEN<\/td>\n<td>Settings &gt; CI\/CD &gt; Token Access<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>OIDC id_tokens<\/td>\n<td><code>.gitlab-ci.yml<\/code><\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>Detecci\u00f3n de Secretos<\/td>\n<td><code>include: template<\/code><\/td>\n<td>Free (Ultimate para dashboard)<\/td>\n<\/tr>\n<tr>\n<td>Push Rules<\/td>\n<td>Settings &gt; Repository &gt; Push Rules<\/td>\n<td>Premium<\/td>\n<\/tr>\n<tr>\n<td>Timeouts de Jobs<\/td>\n<td>Settings &gt; CI\/CD + <code>.gitlab-ci.yml<\/code><\/td>\n<td>Free<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Lecturas Adicionales y Laboratorios<\/h2>\n<p>Contin\u00faa fortaleciendo tus pipelines de GitLab CI\/CD con estos recursos relacionados:<\/p>\n<ul>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/gitlab-ci-cd-security-definitive-guide\/\">Gu\u00eda de Seguridad de GitLab CI\/CD<\/a> \u2014 Un recorrido completo por cada configuraci\u00f3n de seguridad en GitLab CI\/CD.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/secrets-management-ci-cd-pipelines-patterns-vault\/\">Mejores Pr\u00e1cticas de Gesti\u00f3n de Secretos en CI\/CD<\/a> \u2014 Profundizaci\u00f3n en integraci\u00f3n con vault, rotaci\u00f3n y secretos con privilegios m\u00ednimos.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/short-lived-credentials-workload-identity-federation-ci-cd-2\/\">Autenticaci\u00f3n OIDC en Pipelines de CI\/CD<\/a> \u2014 Laboratorio paso a paso para configurar OIDC con AWS, GCP y Azure.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/complete-guide-ci-cd-pipeline-security\/\">Checklist de Seguridad de Pipelines CI\/CD<\/a> \u2014 La lista de verificaci\u00f3n completa que cubre GitHub Actions, GitLab CI y Jenkins.<\/li>\n<li><a href=\"https:\/\/docs.gitlab.com\/ee\/ci\/\" target=\"_blank\" rel=\"noopener\">Documentaci\u00f3n Oficial de GitLab CI\/CD<\/a> \u2014 La referencia autoritativa para todas las funcionalidades de GitLab CI\/CD.<\/li>\n<\/ul>\n<p>La seguridad no es una configuraci\u00f3n de una sola vez \u2014 es una pr\u00e1ctica continua. Revisa la configuraci\u00f3n de seguridad de tus pipelines trimestralmente, rota las credenciales, audita el acceso de los runners y mant\u00e9n tu instancia de GitLab actualizada. Este cheat sheet te da los bloques de construcci\u00f3n. Ahora ve y asegura tus pipelines.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Por Qu\u00e9 Importa la Seguridad en GitLab CI Los pipelines de GitLab CI\/CD son potentes \u2014 pero con ese poder viene el riesgo. Una variable mal configurada puede filtrar secretos. Un runner sin alcance definido puede ejecutar c\u00f3digo malicioso. Un entorno sin protecci\u00f3n puede permitir que un desarrollador junior haga un despliegue directo a producci\u00f3n. &#8230; <a title=\"Cheat Sheet de Seguridad de GitLab CI: Variables, Runners, Entornos y OIDC\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/gitlab-ci-security-cheat-sheet\/\" aria-label=\"Leer m\u00e1s sobre Cheat Sheet de Seguridad de GitLab CI: Variables, Runners, Entornos y OIDC\">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,57],"tags":[],"post_folder":[],"class_list":["post-610","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-gitlab-ci"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/610","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=610"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/610\/revisions"}],"predecessor-version":[{"id":733,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/610\/revisions\/733"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=610"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=610"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=610"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=610"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}