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](https://docs.gitlab.com/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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). 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](https://docs.gitlab.com/ci/cloud_services/aws/)
## Ü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](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance).
## 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](#configure-gitlab-pipeline). Weitere Informationen finden Sie unter [Erstelle ein AWS Secrets Manager Geheimnis](create_secret.md).
1.
**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](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_providers_create_oidc.html) und in der Dokumentation. GitLab](https://docs.gitlab.com/ci/cloud_services/aws/)
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**.
1. Setzen Sie das `audience` oder `aud` auf**sts.amazonaws.com**.
1.
**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)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) übernommen. Weitere Informationen finden [Sie unter Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-custom.html).
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](#step2-oidc-provider)) ein, die Sie in Schritt 2 verwendet haben.
+ Stellen `Audience` Sie dieselbe [Zielgruppe](#step2-oidc-audience) ein, die Sie in Schritt 2 verwendet haben.
1. Im Folgenden finden Sie ein Beispiel für eine Vertrauensrichtlinie, die es ermöglicht GitLab , Rollen zu übernehmen. Ihre Vertrauensrichtlinie sollte Ihren AWS-Konto GitLab URL und Ihren [Projektpfad](https://docs.gitlab.com/user/project/) auflisten.
****
```
{
"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. 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](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"
}
]
}
```
## 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](https://docs.gitlab.com/ci/yaml/yaml_optimization/) 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](https://docs.gitlab.com/ci/variables/#use-file-type-cicd-variables).
Das Folgende ist ein 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](https://docs.gitlab.com/ci/secrets/aws_secrets_manager/).
Optional können Sie Ihre OIDC-Konfiguration in testen. GitLab Weitere Informationen finden Sie in der [GitLab Dokumentation zum Testen der OIDC-Konfiguration](https://docs.gitlab.com/ci/cloud_services/aws/#test-the-oidc-configuration).
## 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:
+ Ihre YAML-Datei ist ordnungsgemäß formatiert. Weitere Informationen finden Sie in der [GitLab-Dokumentation](https://docs.gitlab.com/ee/ci/yaml/).
+ Ihre GitLab Pipeline nimmt die richtige Rolle ein, verfügt über die entsprechenden Berechtigungen und hat Zugriff auf das richtige AWS Secrets Manager Geheimnis.
### Weitere Ressourcen
Die folgenden Ressourcen können Ihnen bei der Behebung von Problemen mit GitLab und helfen AWS Secrets Manager:
+ [GitLab OIDC-Fehlerbehebung](https://docs.gitlab.com/ci/cloud_services/aws/#troubleshooting)
+ [Debuggen GitLab der CI/CD-Pipeline](https://docs.gitlab.com/ee/ci/troubleshooting.html)
+ [Fehlerbehebung](ascp-eks-installation.md#troubleshooting)