2557gelesen 0Kommentare
Wer eine eigene PHP Bibliothek betreibt (z.B. satis) und diese via Basic Authentication vor unerlaubtem Zugriff schützt, benötigt dafür eine Zugriffskonfiguration (sofern diese nicht in der composer.json übermittelt werden sollen). Ich zeige dir die Nutzung der PHP Bibliothek im nachfolgenden Artikel, die dir zeigt, wie du den Schutz in Gitlab-CI überwindest – sprich mit gültigen Daten anmeldest.
~/.composer/auth.json
{
"http-basic": {
"repo.example1.org": {
"username": "my-username1",
"password": "my-secret-password1"
}
}
}
“Traditionelle” Weise
Wenn du allerdings im Bereich von Continouos Integration unterwegs bist und (bspw. Gitlab CI), dann musst du die Konfiguration im Benutzerverzeichnis des CI-Benutzer’s hinterlegen:
user@hostsystem: sudo mkdir -p /home/gitlab-runner/.composer
user@hostsystem: sudo touch /home/gitlab-runner/.composer/auth.json
user@hostsystem: cat <<'EOF' >> /home/gitlab-runner/.composer/auth.json
{
"http-basic": {
"repo.example1.org": {
"username": "my-username1",
"password": "my-secret-password1"
}
}
}
EOF
user@hostsystem: sudo chmod -R 700 /home/gitlab-runner/.composer
Damit verwendet der lokal installierte Runner (sofern der Executor Shell ist) die angelegte Datei. Ganz klarer Nachteil: Die Datei ist statisch angelegt, sofern die Zugangsdaten mit einem Ablaufdatum versehen sind müssen diese wieder ausgetauscht werden. Und das auf jedem System, das einen Runner beinhaltet.
Wie kann man es besser machen?
Unabhängig welchen Executor der Runner (Liste unter docs.gitlab.com/runner/) ausführt können wir diese während der Ausführung in der script-Sektion der .gitlab-ci.yml
Datei hinzufügen.
Als erstes werden die Authentifizierungs-Daten in einer CI-Variable abgelegt. Dazu die Einstellungen des Git-Repository öffnen und in den Unterpunkt CI / CD klicken. Dort Befindet sich der Tab “Variablen”
Hier legst du eine neue Variable an, bspw. Schlüssel: COMPOSER_AUTH
und Wert mit einem generierten Wert, bestehend aus 2 Teilen:
user@hostsystem: openssl rand -base64 12
3Q2SXC0avCC2S98J
user@hostsystem: openssl rand -base64 12
i2+55fiFaG4qUKL5
Die beiden Werte tragen wir zusammengehängt (und mit Doppelpunkt getrennt) in die Wertspalte ein und speichern die Variable. Zusätzlich ist es bei solchen sensiblen Daten anzuraten, dass diese als geschützt gekennzeichnet werden (Protected).
Soweit so gut, jetzt muss der Benutzer noch beim privaten Composer-Repository hinzugefügt werden. Sofern der Webserver ein Indianer (Apache) ist oder ein nginx geht das mit dem Werkzeug htpasswd
(bitte die generierten Werte in der richtigen Reihenfolge verwenden: Vor dem Doppelpunkt=Benutzer; nach dem Doppelpunkt=Passwort)
user@hostsystem: htpasswd [datei] 3Q2SXC0avCC2S98J
New password:
Re-type new password:
Adding password for user 3Q2SXC0avCC2S98J
Zu guter Letzt fügen wir der Datei gitlab-ci.yml
in der Sektion script die notwendige Konfiguration hinzu.
Gitlab-CI: Docker-Executor
prepare code:
stage: build
image: php:7.1-alpine
tags:
- docker
cache:
paths:
- ./vendor
script:
- echo "build test enviroment"
- echo "$COMPOSER_AUTH" > ~/.composer/auth.json
- composer update --prefer-dist --no-ansi --no-interaction --no-progress
Gitlab-CI: Shell-Executor
prepare code:
stage: build
tags:
- shell
cache:
paths:
- ./vendor
script:
- echo "build test enviroment"
- echo "$COMPOSER_AUTH" > ~/.composer/auth.json
- composer update --prefer-dist --no-ansi --no-interaction --no-progress
- rm -f ~/.composer/auth.json
Fazit zur Nutzung einer privaten PHP Bibliothek in Gitlab-CI
Sofern deine private PHP Bibliothek im Internet verfügbar ist, ist es notwendig, dieser zumindest mit einer Authentifizierung zu sichern. Außerdem ist es wenig sinnvoll, im Programm-Code die Daten zu hinterlegen. Demzufolge ist es sinnvoll diese Daten in deiner Gitlab-Konfiguration einzubetten und zu schützen.
Foto: James Sutton