Verwenden Sie AWS Secrets Manager in GitLab - AWS Secrets Manager
ÜberlegungenVoraussetzungenIntegration AWS Secrets Manager mit GitLabFehlerbehebung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie AWS Secrets Manager in GitLab

AWS Secrets Manager integriert mit GitLab. Sie können Secrets Manager Secrets nutzen, um Ihre GitLab Anmeldeinformationen zu schützen, sodass sie nicht mehr fest codiert sind. GitLab Stattdessen ruft GitLab Runner diese Secrets aus Secrets Manager ab, wenn Ihre Anwendung einen Job in den GitLab CI/CD-Pipelines ausführt.

Um diese Integration zu nutzen, erstellen Sie einen OpenID Connect (OIDC) -Identitätsanbieter in IAM AWS Identity and Access Management und eine IAM-Rolle. Dadurch kann GitLab Runner auf Ihr Secrets Manager Manager-Geheimnis zugreifen. Weitere Informationen zu GitLab CI/CD und OIDC finden Sie in der Dokumentation. GitLab

Überlegungen

Wenn Sie eine nicht öffentliche GitLab Instanz verwenden, können Sie diese Secrets Manager Manager-Integration nicht verwenden. Sehen Sie sich stattdessen die GitLab Dokumentation für nicht öffentliche Instanzen an.

Voraussetzungen

Um Secrets Manager mit zu integrieren GitLab, müssen Sie die folgenden Voraussetzungen erfüllen:

  1. Erstellen Sie ein AWS Secrets Manager Geheimnis

    Sie benötigen ein Secrets Manager Manager-Geheimnis, das bei Ihrem GitLab Job abgerufen wird und das Festcodieren dieser Anmeldeinformationen überflüssig macht. Sie benötigen die geheime ID von Secrets Manager, wenn Sie Ihre GitLab Pipeline konfigurieren. Weitere Informationen finden Sie unter Erstelle ein AWS Secrets Manager Geheimnis.

  2. Geben Sie in der IAM-Konsole GitLab Ihren OIDC-Anbieter an.

    In diesem Schritt erstellen Sie GitLab Ihren OIDC-Anbieter in der IAM-Konsole. Weitere Informationen finden Sie unter Erstellen eines OpenID Connect (OIDC) -Identitätsanbieters und in der Dokumentation. GitLab

    Verwenden Sie beim Erstellen des OIDC-Anbieters in der IAM-Konsole die folgenden Konfigurationen:

    1. Stellen Sie das auf Ihre Instanz provider URL ein. GitLab Beispiel, gitlab.example.com.

    2. Setzen Sie das audience oder aud aufsts.amazonaws.com.

  3. Erstellen Sie eine IAM-Rolle und -Richtlinie

    Sie müssen eine IAM-Rolle und -Richtlinie erstellen. Diese Rolle wird von GitLab with AWS Security Token Service (STS) übernommen. Weitere Informationen finden Sie unter Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien.

    1. Verwenden Sie in der IAM-Konsole die folgenden Einstellungen, wenn Sie die IAM-Rolle erstellen:

      • Setzen Sie Trusted entity type auf Web identity.

      • Setzen Sie Group auf your GitLab group.

      • Stellen Identity provider Sie dieselbe Anbieter-URL (die GitLab Instanz) ein, die Sie in Schritt 2 verwendet haben.

      • Stellen Audience Sie dieselbe Zielgruppe ein, die Sie in Schritt 2 verwendet haben.

    2. Sie müssen außerdem eine IAM-Richtlinie erstellen, um den GitLab Zugriff darauf zu AWS Secrets Manager ermöglichen. Sie können diese Richtlinie zu Ihrer Vertrauensrichtlinie hinzufügen. Weitere Informationen finden Sie unter IAM-Richtlinien erstellen.

      Mehr anzeigenWeniger anzeigen

Integration AWS Secrets Manager mit GitLab

Nachdem Sie die Voraussetzungen erfüllt haben, können Sie konfigurieren, GitLab dass Secrets Manager zum Schutz Ihrer Anmeldeinformationen verwendet wird.

GitLab Pipeline für die Verwendung von Secrets Manager konfigurieren

Sie müssen Ihre GitLab CI/CD-Konfigurationsdatei mit den folgenden Informationen aktualisieren:

  • Die Zielgruppe des Tokens ist auf STS festgelegt.

  • Die geheime ID von Secrets Manager.

  • Die IAM-Rolle, die GitLab Runner bei der Ausführung von Jobs in der GitLab Pipeline übernehmen soll.

  • Der AWS-Region Ort, an dem das Geheimnis gespeichert ist.

GitLab ruft das Geheimnis aus Secrets Manager ab und speichert den Wert in einer temporären Datei. Der Pfad zu dieser Datei wird in einer CI/CD Variablen gespeichert, ähnlich wie CI/CD-Variablen vom Dateityp.

Im Folgenden finden Sie einen Auszug aus der YAML-Datei für eine CI/CD-Konfigurationsdatei: 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"

Weitere Informationen finden Sie in der GitLabSecrets Manager Manager-Integrationsdokumentation.

Optional können Sie Ihre OIDC-Konfiguration in testen. GitLab Weitere Informationen finden Sie in der GitLab Dokumentation zum Testen der OIDC-Konfiguration.

Fehlerbehebung

Die folgenden Informationen können Ihnen helfen, häufig auftretende Probleme zu beheben, die bei der Integration von Secrets Manager auftreten können GitLab.

GitLab Probleme mit der Pipeline

Wenn Sie Probleme mit der GitLab Pipeline haben, stellen Sie Folgendes sicher:

Weitere Ressourcen

Die folgenden Ressourcen können Ihnen bei der Behebung von Problemen mit GitLab und helfen AWS Secrets Manager: