Utiliser AWS Secrets Manager dans GitLab - AWS Secrets Manager

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utiliser AWS Secrets Manager dans GitLab

AWS Secrets Manager s'intègre à GitLab. Vous pouvez utiliser les secrets de Secrets Manager pour protéger vos GitLab informations d'identification afin qu'elles ne soient plus codées en GitLab dur. GitLab Runner récupère plutôt ces secrets auprès de Secrets Manager lorsque votre application exécute une tâche dans les pipelines GitLab CI/CD.

Pour utiliser cette intégration, vous allez créer un fournisseur d'identité OpenID Connect (OIDC) dans IAM AWS Identity and Access Management et un rôle IAM. Cela permet à GitLab Runner d'accéder au secret de votre Gestionnaire de Secrets Manager. Pour plus d'informations sur le GitLab CI/CD et l'OIDC, consultez la documentation. GitLab

Considérations

Si vous utilisez une GitLab instance non publique, vous ne pouvez pas utiliser cette intégration de Secrets Manager. Consultez plutôt la GitLab documentation pour les instances non publiques.

Prérequis

Pour intégrer Secrets Manager à GitLab, remplissez les conditions préalables suivantes :

  1. Créez un AWS Secrets Manager secret

    Vous aurez besoin d'un secret de Secrets Manager qui sera récupéré lors de votre GitLab travail et qui vous évitera d'avoir à coder en dur ces informations d'identification. Vous aurez besoin de l'ID secret de Secrets Manager pour configurer votre GitLab pipeline. Pour plus d’informations, consultez Créez un AWS Secrets Manager secret.

  2. Définissez GitLab votre fournisseur OIDC dans la console IAM.

    Au cours de cette étape, vous allez créer GitLab votre fournisseur OIDC dans la console IAM. Pour plus d'informations, consultez la section Création d'un fournisseur d'identité OpenID Connect (OIDC) et documentation. GitLab

    Lorsque vous créez le fournisseur OIDC dans la console IAM, utilisez les configurations suivantes :

    1. Définissez le provider URL sur votre GitLab instance. Par exemple, gitlab.example.com.

    2. Réglez le audience ou aud sursts.amazonaws.com.

  3. Création d'un rôle et d'une politique IAM

    Vous devez créer un rôle et une politique IAM. Ce rôle est assumé par GitLab with AWS Security Token Service (STS). Voir Créer un rôle à l'aide de politiques de confiance personnalisées pour plus d'informations.

    1. Dans la console IAM, utilisez les paramètres suivants lors de la création du rôle IAM :

      • Définissez Trusted entity type sur Web identity.

      • Définissez Group sur your GitLab group.

      • Définissez Identity provider la même URL de fournisseur (l'GitLab instance) que celle que vous avez utilisée à l'étape 2.

      • Définissez Audience le même public que celui que vous avez utilisé à l'étape 2.

    2. Vous devrez également créer une politique IAM pour autoriser l' GitLab accès à AWS Secrets Manager. Vous pouvez ajouter cette politique à votre politique de confiance. Pour plus d'informations, consultez la section Création de politiques IAM.

Intégration AWS Secrets Manager avec GitLab

Une fois les prérequis remplis, vous pouvez configurer l'utilisation GitLab de Secrets Manager afin de protéger vos informations d'identification.

Configurer le GitLab pipeline pour utiliser Secrets Manager

Vous devez mettre à jour votre fichier de configuration GitLab CI/CD avec les informations suivantes :

  • L'audience du jeton définie sur STS.

  • L'identifiant secret du Secrets Manager.

  • Le rôle IAM que vous souhaitez que GitLab Runner assume lors de l'exécution de tâches dans le GitLab pipeline.

  • L' Région AWS endroit où le secret est conservé.

GitLab récupère le secret depuis Secrets Manager et stocke la valeur dans un fichier temporaire. Le chemin d'accès à ce fichier est stocké dans une CI/CD variable, similaire aux variables CI/CD de type de fichier.

Voici un extrait du fichier YAML pour un fichier de configuration GitLab CI/CD :

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"

Pour plus d'informations, consultez la documentation d'intégration de GitLab Secrets Manager.

Vous pouvez éventuellement tester votre configuration OIDC dans GitLab. Consultez GitLab la documentation relative au test de la configuration OIDC pour plus d'informations.

Résolution des problèmes

Les informations suivantes peuvent vous aider à résoudre les problèmes courants que vous pouvez rencontrer lors de l'intégration de Secrets Manager à GitLab.

GitLab Problèmes liés au pipeline

Si vous rencontrez des problèmes de GitLab pipeline, assurez-vous de ce qui suit :

  • Votre fichier YAML est correctement formaté. Pour plus d'informations, consultez GitLabla documentation.

  • Votre GitLab pipeline assume le bon rôle, dispose des autorisations appropriées et a accès au AWS Secrets Manager secret approprié.

Ressources supplémentaires

Les ressources suivantes peuvent vous aider à résoudre les problèmes liés à GitLab et AWS Secrets Manager :