Úselo AWS Secrets Manager en GitLab

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 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 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

Consideraciones

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.

Requisitos previos

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. Para obtener más información, consulte Crea un AWS Secrets Manager secreto.

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

   En este paso, designará 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). GitLab

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

   1. Configúrelo en provider URL su instancia. GitLab Por ejemplo, gitlab.example.com.

   2. Configure el audience o aud ensts.amazonaws.com.

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

   Deberá crear una función y una política de IAM. Esta función la asume GitLab with AWS Security Token Service (STS). Consulte Crear un rol mediante políticas de confianza personalizadas para obtener más información.

   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 providerConfigúrelo en la misma URL del proveedor (la GitLab instancia) que utilizó en el paso 2.

      • AudienceEstablézcalo en la misma audiencia que usaste en el paso 2.

   2. El siguiente es un ejemplo de una política de confianza que GitLab permite asumir roles. Tu política de confianza debe incluir tu Cuenta de AWS GitLab URL y la ruta del proyecto.

      {
        "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*"
                ]
              }
            }
          }
        ]
      }
      

   3. También tendrás que crear una política de IAM para permitir el GitLab acceso a AWS Secrets Manager. Puedes añadir esta política a tu política de confianza. Para obtener más información, consulte Crear políticas de IAM.

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

Mostrar másMostrar menos

Integrar con AWS Secrets Manager GitLab

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

Deberá actualizar el archivo de configuración de GitLab CI/CD con la siguiente información:

• El público del token establecido en STS.

• El identificador secreto de Secrets Manager.

• La función de IAM que quieres que asuma GitLab Runner al ejecutar tareas en GitLab proceso.

• 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.

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.

Si lo desea, puede probar su configuración de OIDC en. GitLab Consulte GitLab la documentación para probar la configuración del OIDC para obtener más información.

Solución de problemas

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

GitLab Problemas de canalización

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.

• Tu GitLab canalización asume la función correcta, tiene los permisos adecuados y acceso al secreto correcto AWS Secrets Manager .

Recursos adicionales

Los siguientes recursos pueden ayudarte a solucionar problemas relacionados con GitLab y AWS Secrets Manager:

• GitLab Solución de problemas del OIDC

• Depuración GitLab de la canalización de CI/CD

• Solución de problemas