Orosu Server

Uit het Japanse 降ろす (órosu) — "uitladen" of "afvoeren."

Het probleem

CI-systemen zijn goed in software bouwen en slecht in software uitleveren. Een buildartefact van een pijplijn naar een productiemachine krijgen betekent meestal een van een handvol bekende maar broze patronen:

• Private SSH-sleutels die in CI-secrets worden gekopieerd en zich verspreiden over elke pijplijn en repository die moet uitrollen
• SFTP/rsync-scripts die van project naar project worden gekopieerd, elk met eigen, net iets andere bugs
• Hardgecodeerde paden en rechten die breken zodra de indeling van een server verandert
• Productiemachines die rechtstreeks bereikbaar zijn vanaf CI-runners, waardoor het aanvalsoppervlak groeit met elke pijplijn die erbij komt
• Wildgroei van secrets waardoor één gecompromitteerde sleutel roteren verandert in een audit van elke repository die ernaar zou kunnen verwijzen

Niets hiervan is eigen aan één CI/CD-platform — het is de standaardvorm van "draai een script op een externe machine vanuit een pijplijn", en het stapelt risico op met elk project dat het overneemt.

Hoe Orosu dat oplost

Orosu wordt één keer op de doelmachine geïnstalleerd als orosu-server en maakt van uitrollen een begrensd, geauthenticeerd verzoek in plaats van een open SSH-sessie:

1. CI bouwt de applicatie — een binary, een container-image, statische assets, wat de pijplijn ook oplevert
2. CI start een taak over een WebSocket-verbinding, eventueel met bestanden erbij
3. orosu-server authenticeert het verzoek met Ed25519-handtekeningen — geen wachtwoorden, geen gedeelde geheimen onderweg
4. orosu-server draait een vooraf vastgelegd script — een uit een vaste set die op de server is ingesteld, nooit willekeurige commando's die CI aanlevert
5. Het script rolt uit, met de bestanden en argumenten die de taak meestuurde

Geen directe SSH, geen gegoochel met credentials per pijplijn, en geen serveroppervlak buiten de specifieke scripts die een beheerder uitdrukkelijk heeft ingesteld.

Installatie

orosu-server en het bijbehorende orosu-keygen-programma worden als Debian- en Ubuntu-pakketten geleverd vanaf een apt-repository:

curl -fsSL https://packages.nerdy.pro/NerdyPro.gpg | sudo gpg --dearmor -o /usr/share/keyrings/nerdy-pro.gpg
echo "deb [signed-by=/usr/share/keyrings/nerdy-pro.gpg] https://packages.nerdy.pro/ stable main" | sudo tee /etc/apt/sources.list.d/nerdy-pro.list
sudo apt update
sudo apt install orosu

GitHub Releases publiceert ook kant-en-klare binaries van orosu-server en orosu-keygen, voor machines die geen apt-bron kunnen toevoegen.

Aan de slag

Genereer een clientsleutelpaar met orosu-keygen, vanuit /etc/orosu:

orosu-keygen --name my-ci-client --private-key-output my-ci-client.key --public-key-output my-ci-client.pub

De publieke sleutel gaat in de serverconfiguratie; de private sleutel wordt een CI-secret.

Stel de server in in /etc/orosu/orosu-server.toml — een luisteradres en de publieke sleutel van de client:

listen:
  tcp: "127.0.0.1:8081"
clients:
  - name: my-ci-client
    secret_file: /etc/orosu/my-ci-client.pub

Een server die aan localhost is gebonden staat doorgaans achter een reverse proxy die TLS afsluit en WebSocket-upgrades doorstuurt — de README documenteert een nginx-configuratie hiervoor.

Leg een script vast dat de client mag starten:

#!/bin/bash
echo "Hello, $1!"

clients:
  - name: my-ci-client
    secret_file: /etc/orosu/my-ci-client.pub
    scripts:
      - name: test-script
        command:
          - "bash"
          - "/etc/orosu/scripts/test.sh"

Start het vanuit CI met de bijbehorende GitHub Action, waarbij je het serveradres en de private sleutel van de client als secrets meegeeft:

- name: Remotely execute a script
  uses: orosu-ci/orosu@v0
  with:
    address: ${{ secrets.OROSU_SERVER_URL }}
    script: test-script
    key: ${{ secrets.OROSU_CLIENT_KEY }}
    arguments: "from CI pipeline"

End-to-end-versleuteling

WSS en TLS dekken de verbinding, maar wanneer TLS wordt afgesloten bij een reverse proxy vóór orosu-server — de standaardopstelling hierboven — zijn scriptargumenten, geüploade bestanden en gestreamde uitvoer bij die proxy leesbare tekst. Een optionele handdruk voor end-to-end-versleuteling (X25519 + HKDF-SHA256 + ChaCha20-Poly1305) dicht dat gat:

orosu-keygen --kind server --private-key-output server.key --public-key-output server.pub

De publieke sleutel van de server wordt aan zijn configuratie toegevoegd en als invoer server_key aan de Action in CI meegegeven. De uitbreiding is optioneel en aan beide kanten onafhankelijk toe te voegen — een server met versleuteling ingesteld bedient clients die server_key weglaten precies zoals voorheen, en een gecoördineerde uitrol is niet nodig.

Beveiliging

Beveiliging is een ontwerpuitgangspunt en geen bijzaak:

• Cryptografische authenticatie — elke taak is ondertekend met de Ed25519-sleutel van de client; er gaat geen wachtwoord of gedeeld geheim over de lijn dat een aanvaller kan onderscheppen.
• Een gesloten set handelingen — CI kan alleen scripts starten die een beheerder uitdrukkelijk op de server heeft vastgelegd. Er is geen weg van een CI-taak naar een willekeurig shellcommando.
• Geharde afhandeling van bijlagen — namen van zip-regels worden getoetst op padmanipulatie, en zowel het aantal regels als de uitgepakte omvang is begrensd, zodat een geprepareerde of te grote bijlage niet uit zijn uitpakmap kan ontsnappen of de schijf kan vullen.
• Versleuteling in lagen — de optionele end-to-end-handdruk controleert op aanvallen met punten van lage orde in de X25519-uitwisseling, boven op de vertrouwelijkheid die ze al biedt.
• Standaard veilige bestandsrechten — orosu-keygen schrijft bestanden met private sleutels met rechten 0600, ongeacht de geldende umask.

Deze beschermingen landden in release 0.7.0 als een directe upgrade — zonder wijzigingen aan configuratie, CLI of protocol. Zie CHANGELOG.md voor de volledige releasegeschiedenis.

Licentie

Orosu valt onder de Apache-2.0-licentie.