

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Uso AWS Secrets Manager en GitLab
<a name="integrating_gitlab"></a>

AWS Secrets Manager se integra con GitLab. Puede aprovechar los secretos de Secrets Manager para proteger sus GitLab credenciales y evitar que estén codificadas GitLab. En su lugar, [GitLab Runner](https://docs.gitlab.com/runner/) recupera estos secretos de Secrets Manager cuando la aplicación ejecuta un trabajo en las canalizaciones de GitLab CI/CD.

Para usar esta integración, creará un [proveedor de identidad OpenID Connect (OIDC) en IAM y un rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) AWS Identity and Access Management . Esto le permite a GitLab Runner acceder a tu secreto de Secrets Manager. [Para obtener más información sobre el GitLab CI/CD y el OIDC, consulte la documentación. GitLab](https://docs.gitlab.com/ci/cloud_services/aws/)

## Consideraciones
<a name="gitlab-integration-considerations"></a>

Si utilizas una GitLab instancia no pública, no puedes usar esta integración de Secrets Manager. En su lugar, consulte [GitLab la documentación de las instancias no públicas](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance).

## Requisitos previos
<a name="gitlab-integration-prerequisites"></a>

Para integrar Secrets Manager con GitLab, complete los siguientes requisitos previos:

1. 

**Crea un secreto AWS Secrets Manager**

   Necesitarás un secreto de Secrets Manager que se recuperará en tu GitLab trabajo y que eliminará la necesidad de codificar estas credenciales de forma rígida. Necesitarás el ID secreto de Secrets Manager cuando [configures tu GitLab canalización](#configure-gitlab-pipeline). Para obtener más información, consulte [Crea un AWS Secrets Manager secreto](create_secret.md).

1. 

**Configura GitLab tu proveedor de OIDC en la consola de IAM.**

   En este paso, seleccionará GitLab su proveedor de OIDC en la consola de IAM. [Para obtener más información, consulte [Crear un proveedor de identidad y la documentación de OpenID Connect (OIDC)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_providers_create_oidc.html). GitLab](https://docs.gitlab.com/ci/cloud_services/aws/)

   Al crear el proveedor de OIDC en la consola de IAM, debe utilizar las siguientes configuraciones:

   1. <a name="step2-oidc-provider"></a>Configúrelo en `provider URL` su instancia. GitLab Por ejemplo, **gitlab.example.com**.

   1. <a name="step2-oidc-audience"></a>Establezca `audience` o `aud` en **sts.amazonaws.com**.

1. 

**Creación de una política y un rol de IAM**

   Deberá crear un rol de IAM y una política. GitLab with [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) asume esta función. Para obtener más información, consulte [Crear un rol mediante políticas de confianza personalizadas](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-custom.html).

   1. En la consola de IAM, utilice la siguiente configuración al crear el rol de IAM:
      + Establece `Trusted entity type` en **Web identity**.
      + Establece `Group` en **your GitLab group**.
      + `Identity provider`Configúrelo en la misma URL del proveedor (la [GitLab instancia](#step2-oidc-provider)) que utilizó en el paso 2.
      + Establezca `Audience` en la misma [audiencia](#step2-oidc-audience) que utilizó en el paso 2.

   1. El siguiente es un ejemplo de una política de confianza que GitLab permite asumir funciones. Tu política de confianza debe incluir tu Cuenta de AWS GitLab URL y la [ruta del proyecto](https://docs.gitlab.com/user/project/).  
****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Principal": {
              "Federated": "arn:aws:iam::111122223333:oidc-provider/gitlab.example.com"
            },
            "Condition": {
              "StringEquals": {
                "gitlab.example.com:aud": [
                  "sts.amazon.com"
                ]
              },
              "StringLike": {
                "gitlab.example.com:sub": [
                  "project_path:mygroup/project-*:ref_type:branch-*:ref:main*"
                ]
              }
            }
          }
        ]
      }
      ```

   1. También tendrás que crear una política de IAM para permitir el GitLab acceso a AWS Secrets Manager. Puede agregar esta política a la política de confianza. Para obtener más información, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html).  
****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:your-secret"
          }
        ]
      }
      ```

## Integrarse con AWS Secrets Manager GitLab
<a name="integrating-aws-secrets-manager-gitlab"></a>

Tras cumplir los requisitos previos, puede configurar GitLab el uso de Secrets Manager para proteger sus credenciales.

### Configurar la GitLab canalización para usar Secrets Manager
<a name="configure-gitlab-pipeline"></a>

Deberá actualizar el [archivo de configuración de GitLab CI/CD](https://docs.gitlab.com/ci/yaml/yaml_optimization/) con la siguiente información:
+ La audiencia del token establecido en STS.
+ El ID del secreto de Secrets Manager.
+ La función de IAM que quieres que asuma GitLab Runner al ejecutar tareas en proceso. GitLab
+ El Región de AWS lugar donde se guarda el secreto.

GitLab obtiene el secreto de Secrets Manager y almacena el valor en un archivo temporal. La ruta a este archivo se almacena en una CI/CD variable, similar a las variables [CI/CD de tipo archivo](https://docs.gitlab.com/ci/variables/#use-file-type-cicd-variables).

El siguiente es un fragmento del archivo YAML para un archivo de configuración de CI/CD: GitLab 

```
variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::111122223333:role/gitlab-role'
job:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret-name"
```

Para obtener más información, consulte la [documentación de integración de GitLab Secrets Manager](https://docs.gitlab.com/ci/secrets/aws_secrets_manager/).

Si lo desea, puede probar su configuración de OIDC en. GitLab Consulte [GitLab la documentación para probar la configuración del OIDC](https://docs.gitlab.com/ci/cloud_services/aws/#test-the-oidc-configuration) para obtener más información.

## Resolución de problemas
<a name="troubleshooting-integration"></a>

Lo siguiente puede ayudarlo a solucionar problemas comunes que pueden surgir al integrar Secrets Manager con GitLab.

### GitLab Problemas de canalización
<a name="gitlab-pipeline-issues"></a>

Si tienes problemas con la GitLab canalización, asegúrate de lo siguiente:
+ El archivo YAML tiene el formato correcto. Para obtener más información, consulte [Documentación de GitLab](https://docs.gitlab.com/ee/ci/yaml/).
+ Tu GitLab canalización asume la función correcta, tiene los permisos adecuados y acceso al AWS Secrets Manager secreto correcto.

### Recursos adicionales
<a name="additional-resources"></a>

Los siguientes recursos pueden ayudarte a solucionar problemas relacionados con GitLab y AWS Secrets Manager:
+ [GitLab Solución de problemas del OIDC](https://docs.gitlab.com/ci/cloud_services/aws/#troubleshooting)
+ [Depuración GitLab de la canalización de CI/CD](https://docs.gitlab.com/ee/ci/troubleshooting.html)
+ [Resolución de problemas](ascp-eks-installation.md#troubleshooting)