Verbinden Sie Gitlab CI/CD nahtlos mit AWS: Gitlab AWS-Anmeldungshilfe

In diesem Blog zeigen wir Ihnen, wie Sie sich mit unserem Gitlab AWS Credential Helper ganz einfach mit einem AWS-Konto verbinden können, indem Sie das Gitlab Pipeline-ID-Token als Identität verwenden.

Einführung

Seit Juni 2022 stellt Gitlab JWT-Identitäts-Tokens für jede Projekt-Pipeline zur Verfügung, die über den API-Aufruf assume-role-with-web-identity gegen AWS-Zugangsdaten ausgetauscht werden können. Das ist großartig, denn so können Sie die AWS-Berechtigungen für jede einzelne Pipeline konfigurieren. Das Problem ist jedoch, dass der Austausch des Tokens gegen Anmeldeinformationen ein wenig Shell-Programmierung erfordert. Etwas in der Art der folgenden Zeilen:

ROLE_ARN=$1
WEB_IDENTITY_TOKEN=$2
ROLE_SESSION_NAME=gitlab-${CI_PROJECT_PATH_SLUG}-${CI_PIPELINE_ID}

CREDENTIALS=($(aws sts assume-role-with-web-identity 
        --role-arn ${ROLE_ARN} 
        --role-session-name ${ROLE_SESSION_NAME} 
        --web-identity-token "${WEB_IDENTITY_TOKEN}" 
        --duration-seconds 3600 
        --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' 
        --output text))

aws configure set aws_access_key_id "${CREDENTIALS[0]}"
aws configure set aws_secret_access_key "${CREDENTIALS[1]}"
aws configure set aws_session_token "${CREDENTIALS[2]}"

Wie Sie sehen können, ist das ein ziemlich komplexes Shell-Skript. Das wird in Ihrem nicht schön aussehen, und Sie werden es wahrscheinlich als separates Skript zu Ihrem Projekt hinzufügen. Für ein einzelnes Projekt ist das in Ordnung, aber wenn Sie es auf alle Ihre Projekte anwenden wollen, ist es nicht gut skalierbar: Da dieses Skript nicht für alle Situationen geeignet ist, werden Sie wahrscheinlich auch einige Varianten verwenden.

Gitlab AWS Credential Helper als Retter in der Not

Hier kommt der gitlab aws credential helper ins Spiel! Das Dienstprogramm ist flexibel und sehr einfach in allen möglichen Situationen zu verwenden. Es ist einfach zu konfigurieren, da es nur die AWS-Kontonummer und das Gitlab-ID-Token benötigt. Der Gitlab-Projektpfad-Slug und die Pipeline-ID werden zur Bestimmung des IAM-Rollen- und Sitzungsnamens verwendet. Die allgemeine Konfiguration der CI/CD-Pipeline besteht aus den folgenden fünf Schritten:

• Fügen Sie das Gitlab ID-Token hinzu
• Setzen Sie die AWS-Variablen
• Konfigurieren Sie den Credential Helper
• Erstellen Sie die IAM-Rolle für die Pipeline
• Installieren Sie den Credential Helper

Lassen Sie uns diese fünf Schritte in den folgenden Abschnitten durchgehen.

Gitlab ID-Token hinzufügen

Um ein Gitlab ID-Token in Ihren Pipeline-Aufträgen zu erhalten, fügen Sie die folgende Definition zu Ihrer Pipeline-Definition hinzu:

default:
  id_tokens:
    GITLAB_AWS_IDENTITY_TOKEN:
      aud: https://gitlab.com

Dies führt dazu, dass jeder Auftrag eine Umgebungsvariable namens GITLAB_AWS_IDENTITY_TOKEN mit dem von Gitlab signierten JWT-Identitäts-Token als Wert hat. Der Credential Helper erwartet das Token in dieser Variable.

AWS-Variablen festlegen

Um zu wissen, mit welchem AWS-Konto Sie sich verbinden müssen, fügen Sie die Umgebungsvariable GITLAB_AWS_ACCOUNT_ID mit Ihrer AWS-Kontonummer hinzu:

variables:
  GITLAB_AWS_ACCOUNT_ID: '1234567898012'

Wenn Sie viele Gitlab-Projekte haben, können Sie diese Variable auch als CI/CD-Variable auf Gruppenebene festlegen. Wir empfehlen Ihnen, auch die folgenden Variablen hinzuzufügen:

variables:
  - AWS_CONFIG_FILE: ${CI_PROJECT_DIR}/.aws/config
  - AWS_SHARED_CREDENTIALS_FILE: ${CI_PROJECT_DIR}/.aws/credentials
  - AWS_PROFILE: default

Diese stellen sicher, dass die Konfigurationen der Anmeldeinformationen im Rahmen des Pipeline-Builds beibehalten werden und dass die erhaltenen Anmeldeinformationen tatsächlich verwendet werden.

Verwendung des Credential Helper

Jetzt können Sie den Credential Helper auf eine von drei verschiedenen Arten verwenden:

• als Anmeldungsprozess
• als gemeinsame Anmeldeinformationen gespeichert
• als Umgebungsvariablen

Schauen wir uns jede dieser Optionen an.

Als Anmeldungsprozess

Am elegantesten ist es, den Credential Helper als AWS Credential Process zu konfigurieren, wie unten gezeigt:

before_script:
  - >
    aws config --profile default 
    set credential_process 
    "gitlab-aws-credential-helper process"

script:
  - aws --profile default sts get-caller-identity

Das AWS SDK ruft den Credential Helper immer dann auf, wenn es einen Zugang zu AWS benötigt!

Als gemeinsame Anmeldeinformationen gespeichert

Alternativ kann der Helfer die AWS-Anmeldedaten auch direkt in der Datei mit den gemeinsamen AWS-Anmeldedaten speichern. Sie können dies wie folgt tun:

before_script:
  - >
    gitlab-aws-credential-helper aws-profile 

script:
  - aws --profile default sts get-caller-identity

Dies speichert die Anmeldedaten in der gemeinsamen Anmeldedaten-Datei, normalerweise ~/.aws/credentials.

Als Umgebungsvariablen erhalten

Schließlich können Sie den Helfer verwenden, um die Umgebungsvariablen AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
und AWS_SESSION_TOKEN zu exportieren, wie unten gezeigt:

script:
  - eval $(gitlab-aws-credential-helper env --export)
  - aws sts get-caller-identity

Alternativ können Sie den Befehl auch direkt ausführen:

script:
  - gitlab-aws-credential-helper env -- aws sts get-caller-identity

Erstellen Sie die IAM-Rolle für die Pipeline

Sobald die Pipeline vorbereitet ist, müssen Sie die IAM-Rolle für die CI/CD-Pipeline hinzufügen. Der Name der Rolle sollte dem Namen des Gitlab-Projektpfads Slug entsprechen, wie er durch die Variable CI_PROJECT_PATH_SLUG definiert ist, mit dem Präfix . Die folgende CloudFormation-Vorlage zeigt ein Beispiel für eine IAM-Rollendefinition:

AWSTemplateFormatVersion: '2010-09-09'
Description: Role for gitlab pipeline with limited AWS access
Parameters:
  RepositoryPath:
    Description: the gitlab repository path
    Type: String
  RepositoryPathSlug:
    Description: the gitlab repository path slug
    Type: String
Resources:
  GitlabPipeline:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub 'gitlab-${RepositoryPathSlug}'
      MaxSessionDuration: 3600
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRoleWithWebIdentity
            Principal:
              Federated: !Sub 'arn:aws:iam::${AWS::AccountId}:oidc-provider/gitlab.com'
            Effect: Allow
            Condition:
              ForAnyValue:StringLike:
                "gitlab.com:sub":
                  - !Sub "project_path:${RepositoryPath}:ref_type:branch:ref:*"
      Policies:
        - PolicyName: MetaInformationAccess
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - sts:GetCallerIdentity
                Resource:
                  - '*'

Die Vorlage setzt voraus, dass Sie den OIDC-Anbieter für gitlab.com bereits in Ihrem Konto erstellt haben. Falls nicht, lesen Sie diesen Blog.

Um die gewünschte Rolle zu erstellen, geben Sie ein:

CI_PROJECT_PATH=mvanholsteijn/aws-credential-helper-demo
CI_PROJECT_PATH_SLUG=mvanholsteijn-aws-credential-helper
aws cloudformation deploy 
  --stack-name gitlab-$CI_PROJECT_PATH_SLUG 
  --template-file gitlab-pipeline-limited-access.yaml 
  --capabilities CAPABILITY_NAMED_IAM 
   --parameter-overrides 
     "RepositoryPath=$CI_PROJECT_PATH" 
     "RepositoryPathSlug=$CI_PROJECT_PATH_SLUG"

Das ist alles, was Sie für eine Pipeline benötigen. In den folgenden beiden Abschnitten erfahren Sie, wie Sie den Credential Helper installieren und wie Sie die Standardeinstellungen außer Kraft setzen können.

Installieren Sie den Credential Helper

Natürlich muss in Ihrem Job der gitlab-aws-credential-helper installiert sein. Wir empfehlen, ihn mit einer mehrstufigen Docker-Build-Datei zu dem Image hinzuzufügen, mit dem Ihr Job ausgeführt wird, wie unten gezeigt:

FROM ghcr.io/binxio/gitlab-aws-credential-helper:0.3.2 as gitlab-aws-credential-helper

FROM <yourimage>

COPY --from=gitlab-aws-credential-helper /usr/local/bin/gitlab-aws-credential-helper /usr/local/bin

Wenn Sie Ihr eigenes Runner-Image nicht verwalten, können Sie den folgenden Befehl in den Abschnitt before_script einfügen.

NAME=gitlab-aws-credential-helper
RELEASE=0.3.2
URL=https://github.com/binxio/$NAME/releases/download/${RELEASE}/${NAME}_${RELEASE}_linux_amd64.tar.gz
CHECKSUM=b8c84f1ca5622f4b0f529eca74e7689ea20418eab31a96666366ae1e1531b41f
ARCHIVE="$(basename $URL)"

cd /tmp && 
    curl -L -O -sS $URL && 
    (echo "$CHECKSUM  $ARCHIVE" | sha256sum -c -) && 
    tar -C /usr/local/bin/ -xzf $ARCHIVE && 
    rm -f $ARCHIVE

Standardeinstellungen überschreiben

Der Credential Helper verwendet sinnvolle Standardeinstellungen, um es so einfach wie möglich zu machen. Natürlich können Sie alle Optionen über Umgebungsvariablen oder über die Befehlszeile außer Kraft setzen. Das folgende Beispiel zeigt, wie Sie verschiedene Profile für eine bestimmte Rolle in verschiedenen Konten erstellen können:

before_script:
  ->
    gitlab-aws-credential-helper
    aws-profile --name development
    --aws-account 111111111111 
    --role Deployer
  ->
    gitlab-aws-credential-helper
    aws-profile --name test
    --aws-account 222222222222 
    --role Deployer
  ->
    gitlab-aws-credential-helper
    aws-profile --name production
    --aws-account 333333333333 
    --role Deployer

Verwenden Sie das Flag --help, um einen Überblick über alle möglichen Optionen für jede der Befehlsverwendungen zu erhalten.

Fazit

Mit dem Gitlab AWS Credential Helper ist es ganz einfach, jede Gitlab CI/CD-Pipeline mit den geringstmöglichen Privilegien auszustatten, die für die Ausführung ihrer Aufgaben auf AWS erforderlich sind. Konfigurieren Sie einfach die AWS-Kontonummer, fügen Sie den Credential Helper zum Runner hinzu und erstellen Sie eine IAM-Rolle für jedes Gitlab-Projekt.