Konfigurieren Sie OpenID Connect für GitLab und AWS

Einführung

In Cloud-Projekten wird eine Mischung aus DevOps-Tools verwendet Projekten. Aus bestimmten Gründen bevorzugen wir die Arbeit mit nativen AWS-Tools und -Services. Einer der Gründe (aber sicher nicht der einzige) für diese Meinung ist, dass native Tools eine nahtlose Integration mit den Grundlagen von AWS selbst bieten. Denken Sie an die enge Integration mit AWS Identity and Access Management (IAM) oder AWS CloudTrail. In AWS ist es üblich, den Ressourcen Rollen zuzuweisen.

Für Zum Beispiel, Schritte in CodeBuild ('build runners' in CodePipeline) verfügen über eine IAM-Rolle mit den am wenigsten privilegierten Richtlinien, die ihnen Zugriff auf die Plattform gewährt. Die Rollen verwenden kurzlebige Anmeldeinformationen und werden nativ von der Plattform bereitgestellt. Die Lebensdauer variiert je nach Dienst, liegt aber meist zwischen 15 Minuten und 6 Stunden. Das ist viel kürzer als bei statischen Anmeldedaten, die theoretisch alle 90 Tage ausgetauscht werden sollten. Die Realität ist, dass die manuelle Erneuerung statischer Zugangsdaten sehr mühsam ist und (fast) niemand sie durchführt.

Zugangsdaten sind ein immer wiederkehrendes Thema bei der Integration von Drittanbietern. Die meisten Anbieter unterstützen die AWS Access Key ID und den Secret Access Key, bei denen es sich um statische Anmeldeinformationen handelt, die eine manuelle Rotation erfordern. Diese Anmeldeinformationen werden in der Regel in einem Tresor gespeichert und von dem Tool des Drittanbieters bei der Authentifizierung von API-Aufrufen bei AWS verwendet. Alle 90 Tage muss ein Techniker neue Anmeldeinformationen erstellen, die Konfiguration der Anwendung aktualisieren und dann schließlich den vorherigen Satz von Anmeldeinformationen deaktivieren und löschen.

Aber es gibt gibt es Hoffnung. Immer mehr Anbieter fügen ihrer Software Unterstützung für OpenID Connect (OIDC) hinzu. OIDC ist eine Authentifizierungsschicht, die auf dem OAuth 2.0 Framework aufbaut. Sie wird zur Authentifizierung von Identitäten mit einem externen Identitätsanbieter verwendet. AWS bietet Unterstützung für OIDC unter Verwendung externer Identitätsanbieter und der Übernahme von IAM-Rollen mit temporären Anmeldeinformationen.

GitLab

In diesem Blog nehmen wir GitLab als Beispiel. GitLab ist eine vollständige DevOps-Plattform, einschließlich CI/CD-Funktionen. Sie wird von vielen Unternehmen genutzt, verfügt über eine angemessene AWS-Unterstützung und kann als SaaS-Service in Anspruch genommen werden. GitLab unterstützt OpenID Connect und kann als Identitätsanbieter fungieren. In diesem Abschnitt beschreibe ich, wie GitLab in Verbindung mit AWS genutzt werden kann, ohne dass statische Anmeldedaten verwendet werden müssen.

Es ist gut, ein Verständnis dafür zu haben, wie die Dinge funktionieren, bevor man sich an die Konfiguration macht. In diesem Beispiel möchten wir GitLab für die kontinuierliche Bereitstellung verwenden. Wir möchten also die AWS-Infrastruktur über eine in GitLab ausgeführte Pipeline bereitstellen und bereitstellen.

• Die Pipeline wird durch eine Änderung im Versionskontroll-Repository ausgelöst.

• Der Auftrag wird von einer GitLab-Runner-Instanz erstellt und ausgeführt. Der Runner wird mit Kontext versorgt, einschließlich eines JSON-Web-Tokens (JWT).

• Dieses Authentifizierungs-Token wird verwendet, um AssumeRoleWithWebIdentity auf AWS aufzurufen. Im Gegenzug stellt AWS eine Reihe von temporären Anmeldeinformationen zur Verfügung.

• Verwendet die temporären Anmeldeinformationen für den Zugriff auf AWS-Services und die Bereitstellung von Ressourcen.

• Nachdem die Bereitstellung abgeschlossen ist, wird der Runner beendet und die temporären Anmeldeinformationen laufen ab (Standardwert 3600 Sekunden).

In dieser Konfiguration fungiert GitLab als der Identitätsanbieter, GitLab Runners als Client und AWS als App.

AWS konfigurieren

Der erste Schritt besteht darin, AWS mitzuteilen, dass wir einen externen Identitätsanbieter haben. Dies geschieht durch die Erstellung eines neuen Identitätsanbieters in der Datei IAM-Konsole. Stellen Sie sicher, dass Sie OpenID Connect als Providertyp auswählen. Die Provider-URL ist die URL Ihrer GitLab-Instanz. Für SaaS-gehostetes GitLab lautet die URL gitlab.com. Für selbst gehostete Versionen verwenden Sie gitlab.yourdomain.tld (muss mit https:// beginnen und nicht mit include ein nachgestelltes "/"). Klicken Sie auf Miniaturansicht abrufen, um die Miniaturansicht des Zertifikats des Anbieters zu erhalten. Geben Sie schließlich die Audience- oder Client-ID an. Dies ist wieder derselbe Wert, der auch für die Provider-URL verwendet wird. Klicken Sie auf Anbieter hinzufügen, um den neuen Anbieter zu erstellen.

Jetzt, da der Anbieter erstellt wurde, kann die Rolle kann erstellt werden kann erstellt werden. Gehen Sie zum Abschnitt Rolle erstellen in der IAM-Konsole und erstellen Sie eine neue Rolle mit der Webidentität als vertrauenswürdige Entität. Wählen Sie den Identitätsanbieter und die Zielgruppe, die Sie im vorherigen Schritt erstellt haben. Klicken Sie auf Weiter und erstellen Sie eine Richtlinie. Kopieren Sie die Richtlinie aus dem unten stehenden JSON-Ausschnitt und fügen Sie sie ein:

{
  "Version": "2012-10-17",
  "Erklärung": [  {
  "Sid": "GitLabPolicy",
  "Wirkung": "Erlauben",
  "Aktion": "sts:GetCallerIdentity",
  "Ressource": "*"
  }
  ]
}

Klicken Sie auf Weiter, bis Sie die Seite "Richtlinie überprüfen" sehen. Geben Sie nun einen Namen ein, z.B. gitlab-policy und klicken Sie abschließend auf Richtlinie erstellen. Kehren Sie nun zu der Registerkarte/dem Fenster zurück, in dem wir mit der Erstellung der Rolle begonnen haben. Klicken Sie auf die Schaltfläche Aktualisieren und wählen Sie die im vorherigen Schritt erstellte Richtlinie aus. Klicken Sie auf Weiter. Geben Sie nun einen Namen für die Rolle ein und klicken Sie auf Rolle erstellen. Die Rolle wird nun erstellt. Suchen Sie nun auf der Rollenübersichtsseite nach der Rolle. Öffnen Sie die Rolle und kopieren Sie den ARN. Diese sollte in der Syntax arn:aws:iam::<account-id>:role/<name of the role> vorliegen.

Jetzt haben wir eine Rolle erstellt, aber im Grunde könnte jeder GitLab-Kunde diese Rolle übernehmen. Wir müssen dies durch Hinzufügen einer Bedingung in das Dokument zur Rollenübernahme einschränken. Gehen Sie auf die Registerkarte Vertrauensbeziehungen und ersetzen Sie die bestehende Bedingung durch:

{
  "Bedingung": {
  "StringEquals": {
  "gitlab.com:sub": "projekt_pfad:mygroup/myproject:ref_type:branch:ref:main"
  }
  }
}

Die endgültige Trust-Policy sollte wie folgt aussehen:

{
  "Version": "2012-10-17",
  "Erklärung": [
  {
  "Wirkung": "Erlauben",
  "Principal": {
  "Föderiert": "arn:aws:iam:::oidc-provider/gitlab.com"
  },
  "Aktion": "sts:AssumeRoleWithWebIdentity",
  "Bedingung": {
  "StringEquals": {
  "www.gitlab.com:sub": "projekt_pfad:mygroup/myproject:ref_type:branch:ref:main"
  }
  }
  }  
  ]
}

Weitere Felder, die in der Bedingung verwendet werden können, finden Sie hier.

Konfigurieren Sie OpenID Connect in GitLab

Nach der Konfiguration von AWS können Sie nun Ihr GitLab-Projekt so konfigurieren, dass es temporäre Anmeldeinformationen vom AWS Security Token Service (STS) abruft. Fügen Sie zunächst eine neue Variable zu Ihrem Projekt hinzu. Der Name dieser Variable ist ROLE_ARN und der Wert sollte exakt dem ARN der zuvor erstellten Rolle entsprechen. Die Variable CI_JOB_JWT_V2 ist von GitLab vordefiniert und enthält das aktuelle JWT-Token.

Fügen Sie nun den folgenden Schritt zu Ihren Jobs in .gitlab.yml hinzu:

übernehmen_Rolle:
  Skript:
  -  >
  STS=($(aws sts assume-role-with-web-identity
  --role-arn ${ROLE_ARN}
  --role-session-name "gitlab-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
  --web-identity-token ${CI_JOB_JWT_V2}
  --abfragen 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
  --output text))  
  - export AWS_ACCESS_KEY_ID="${STS[0]}"
  - export AWS_SECRET_ACCESS_KEY="${STS[1]}"
  - export AWS_SESSION_TOKEN="${STS[2]}"
  - aws sts get-anrufer-identität

• Nach den obigen Schritten können Sie Ihre Befehle zur Bereitstellung von AWS-Ressourcen auslösen, zum Beispiel cdk deploy oder terraform apply.

• Möglicherweise möchten Sie den optionalen Parameter -duration-seconds an den Timeout Ihres Auftrags in GitLab anpassen. Die meisten CD-Aufträge auf AWS werden innerhalb von 3600 beendet, aber manchmal ist eine längere Ablaufzeit erforderlich.

• Zusätzlich zu den statischen Anmeldedaten wird ein drittes Schlüssel/Wert-Paar namens AWS_SESSION_TOKEN für dynamische Anmeldedaten hinzugefügt. Es ist in dem obigen Beispiel enthalten. Aber vergessen Sie diese Variable nicht.

• Zu Debugging-Zwecken wurde der Befehl - aws sts get-caller-identity hinzugefügt. Sie können diesen Befehl entfernen, wenn Sie möchten.

• In einem realen Szenario müssen Sie die Police wahrscheinlich verlängern.

Starten Sie nun Ihre Pipeline, indem Sie eine Änderung in Ihr Versionskontroll-Repository übertragen. Der Befehl get-caller-identity sollte ein Ergebnis wie dieses liefern:

{ "UserId": "AROA<user-id>", "Konto": "<account-id>", "Arn": "arn:aws:sts::<konto-id>:assumed-role/<Rollen-Name>/<gitlab-project-id>-<gitlab-pipeline-id>" }

Sie haben nun erfolgreich einen Identitätsfluss zwischen GitLab und AWS mit kurzlebigen Anmeldeinformationen eingerichtet. Auf diese Weise können Sie nodonon nicht mehr müssen Sie keine statischen AWS-Anmeldedaten mehr sichern und rotieren.

In den obigen Schritten haben wir die Ressourcen manuell erstellt, um ein gutes Verständnis für alle erforderlichen Schritte zu bekommen. In Produktionsumgebungen sollten Sie die Ressourcen mit Infrastructure as Code bereitstellen. Alles zusammen in AWS CDK (v2):

import { App, Stack, StackProps, CfnOutput } from 'aws-cdk-lib';
importieren Sie { Construct } von 'constructs';

import { aws_iam as iam } from 'aws-cdk-lib';

interface GitLabOidcProps extends StackProps {
  gitLabURI: Zeichenkette;
  gitLabProjectPath: Zeichenkette;
};

export class GitLabOidc extends Stack {
  constructor(scope: Construct, id: string, props: GitLabOidcProps) {
  super(scope, id, props);

  // Konfigurieren Sie den OIDC-Anbieter
  // Siehe https://docs.gitlab.com/ee/ci/cloud_services/aws/#add-the-identity-provider
  const oidcProvider = new iam.OpenIdConnectProvider(this, 'Provider', {
  url: props.gitLabURI,
  clientIds: [ props.gitLabURI, ],
  });

  // Erstellen Sie die Rolle
  const role = new iam.Role(this, 'Role', {
  assumedBy: new iam.OpenIdConnectPrincipal(oidcProvider).withConditions({
  'StringEquals': {
  [ props.gitLabURI.substring(8) + ':sub' ]: 'project_path:' + props.gitLabProjectPath,
  }
  }),
  description: 'GitLab Pipeline Rolle',
  });

  // Erstellen Sie die Richtlinie, die mit der Rolle verknüpft werden soll.
  // Hinweis: Dies ist ein Beispiel, benötigt  
  const policy = new iam.ManagedPolicy(this, 'Policy', {
  Aussagen: [
  new iam.PolicyStatement({
  sid: 'GitLabPolicy',
  Aktionen: [ 'sts:GetCallerIdentity', ],
  Ressourcen: [ '*', ],
  }),
  ],
  });
  role.addManagedPolicy(policy);

  new CfnOutput(this, 'pipelineRoleArn', {
  Wert: role.roleArn,
  description: 'Rolle ARN, die von der Pipeline übernommen werden soll',
  });
  }
}

// für die Entwicklung, verwenden Sie Konto/Region aus cdk cli
const devEnv = {
  Konto: process.env.CDK_DEFAULT_ACCOUNT,
  Region: process.env.CDK_DEFAULT_REGION,
};

const app = new App();
new GitLabOidc(app, 'MyGitLabIntegration', {
  env: devEnv,
  gitLabURI: 'https://gitlab.com',
  gitLabProjectPath: 'mygroup/myproject:ref_type:branch:ref:main',
});

In diesem Beitrag über OpenID Connect geht es um die Konfiguration von GitLab für die Bereitstellung in AWS, aber etwas Ähnliches kann auch für andere DevOps-Tools gemacht werden. Zum Beispiel mit GitHub und Azure DevOps. Aber AWS hat auch eine Menge neuer cooler Dinge veröffentlicht. Sehen Sie sich meine früheren Blogs an!