Első lépések

Ez az oldal egy friss Linux gépet visz el egy futó átjáróig, az első identitással: telepíted, elindítod, ráállítod egy címtárra, és ellenőrzöd az eredményt. Innen a két képesség útja elválik: az első SSH-munkamenet egy célgépen az első SSH-munkamenet, az első webes konzol az ISG-belépés mögött az alkalmazások beállítása lapon áll. Minden, ami itt következik, a szállított alapértelmezés, hacsak nincs másképp jelezve; a teljes felületet a parancs-referencia és a konfigurációs referencia írja le.

Előfeltételek

Egy Linux gép az átjárónak. Az ISG egyetlen binárisként szállítódik. A Go a megépítéséhez kell (1.26 vagy újabb), a futtatásához nem, tehát az átjáró gépén nincs szükség nyelvi futtatókörnyezetre, alkalmazásszerverre és adatbázisra.

Egy OS-fiók a daemonnak, és egy csoport az operátoroknak. A csomagolt szolgáltatás az isg felhasználóként fut, isg-operators elsődleges csoporttal, és ezen a kettéválasztáson nyugszanak a jogosultságok: a CA privát kulcsai az isg tulajdonában vannak és rajta kívül senki nem olvashatja őket, miközben az átjáró lokális socketjei az isg-operators-hoz tartoznak, így egy operátor elér hozzájuk anélkül, hogy bármelyik kulcsot elolvashatná.

Hálózati elérés a célgépekhez a TCP 22-n. Az átjáró az egyetlen, ami kapcsolódik hozzájuk.

Két további dolog ezen a ponton még opcionális, de kell, mielőtt az átjáró termelésben bármire jó lenne: egy címtár (LDAP vagy Active Directory) az operátorok és a csoporttagságaik feloldásához, és egy SMTP-továbbító, ha a többfaktoros kódokat e-mailben kell kézbesíteni, nem hitelesítő alkalmazással.

Telepítés

Tedd a binárist oda, ahol a service unit keresi:

install -m 0755 isg /usr/local/bin/isg

A repó egy systemd unitot szállít a packaging/isg-ui.service alatt. Telepítsd rootként:

cp packaging/isg-ui.service /etc/systemd/system/isg-ui.service
systemctl daemon-reload
systemctl enable --now isg-ui.service
systemctl status isg-ui.service

Amit ez a unit deklarál, és hogy melyik sor miért van ott:

[Service]
User=isg
Group=isg-operators
Environment=ISG_HOME=/var/lib/isg
RuntimeDirectory=isg
RuntimeDirectoryMode=0750
ExecStart=/usr/local/bin/isg serve --bind 0.0.0.0 --port 8765 \
          --issue-sock-mode 0660 --session-sock-mode 0660
Restart=on-failure
RestartSec=10s

A Group=isg-operators szándékosan a folyamat elsődleges csoportja: a futásidejű könyvtár és a benne lévő socketek ezt öröklik, Group=isg mellett pedig az operátorok egyáltalán nem érnék el őket. A RuntimeDirectoryMode=0750 engedi őket belépni a /run/isg-be, hogy név szerint nyithassanak meg egy socketet anélkül, hogy kilistázhatnák a könyvtárat.

Figyelj rá, hogy ez a unit a 0.0.0.0-ra köt, az átjáró pedig megtagadja a nem-loopback bindolást mindaddig, amíg a hitelesítés és a TLS is a helyén nincs. A unitot az alábbi első-indítás és első-identitás lépések után engedélyezd, különben az első systemctl start hibával áll meg, megnevezve, mi hiányzik. Ez a megtagadás a lényeg — ez az egyetlen dolog, ami egy elrontott konfiguráció és egy hitelesítetlen admin felület közé áll a hálózaton.

A CLI-úthoz ezen túl semmi más nem kell az átjáró gépén. Az isg system provision, ami az SSH-átjárós bejelentkezési úthoz hozza létre az OS-csoportot és a fiókot, egy másik belépési ponthoz tartozik, és az isg connect futtatásához nincs rá szükség.

Ez a lap a kézi, egygépes utat írja le; egy flottát — több brókert egy közös cím mögött, megosztott tárral, címtárral — Ansible-lel telepítünk, a flotta-telepítés lap szerint.

Első indítás

Futtasd a daemont egyszer előtérben, loopbacken, hogy lásd, mit hoz létre:

isg serve

Kiírja, mit vett birtokba és mit nyitott meg:

[ISG] State root lease: /var/lib/isg/serve.lease (held by pid 1234)
[ISG] Local session socket: /run/isg/session.sock (mode 0660)
[ISG] Local issuance socket: /run/isg/issue.sock (mode 0600)
[ISG] CA not initialized — renew endpoint not started (run `isg ca init` first)
[ISG] Admin UI: http://127.0.0.1:8765/
[ISG] Press Ctrl+C to stop.

Az állapotgyökér (state root) az, ahol mindez él. Egyetlen sorrendben oldódik fel, és csak abban: $ISG_HOME, ha be van állítva, aztán az /etc/isg/isg.conf home: kulcsa, ha az a fájl létezik, végül a ~/.isg. A csomagolt unit az ISG_HOME=/var/lib/isg-t állítja be; egy rendszerszintű /etc/isg/isg.conf az a mód, amivel minden fiók — a sudo és a cron is — ugyanarra a fára oldódik fel anélkül, hogy bármit exportálni kellene.

Az első indítás létrehozza az állapotgyökeret, kizárólagos bérletet vesz rá, megnyitja az audit.log-ot, és beköti a lokális socketeket. Konfigurációs fájlokat nem hoz létre: a teljesen konfigurációtlan állapotgyökér érvényes első-futás állapot, és minden fájl hiányának meghatározott jelentése van. A CA-ról szóló sor nem hiba — a daemon CA nélkül is kiszolgál; csak kiadni nem tud még semmit.

Egy állapotgyökeret egyszerre csak egy daemon birtokolhat. Ha egy indítás azért akad el, mert a bérletet más tartja, az isg system lease status megmondja, hogy ki tartja, és hogy az a folyamat él-e még.

Az ISG webUI belépő oldala: a felhasználónév- és a jelszómező, a belépés gomb, alatta pedig a céges fiókkal (SSO) való belépés gombja

Képernyőkép: referencia-környezet (env1), 2026-10-17.

Első identitás

ldap.yaml nélkül az admin felület bejelentkezés nélkül fut, és a jóváhagyási döntéseket semmi nem veti össze egy csoporttal. A négy szem elve továbbra is áll — a saját kérését senki nem hagyhatja jóvá —, de arra, hogy „ki hagyhat jóvá egyáltalán", semmi nem ad választ. A címtárat még azelőtt konfiguráld, hogy az átjáró elhagyná a loopbacket.

Egy minimális ldap.yaml az állapotgyökérben:

url: "ldaps://directory.example.com:636"
tls_ca_file: "/etc/pki/ca-trust/source/anchors/example-root.pem"
bind_dn: "cn=isg,ou=service,dc=example,dc=com"
bind_password: "…"
base_dn: "ou=people,dc=example,dc=com"
group_base_dn: "ou=groups,dc=example,dc=com"
user_attr: "uid"
timeout_seconds: 5
approver_group: "approvers"

A url azért ldaps://, mert egy titkosítatlan megtagadja az indulást: azok az operátor-jelszavak, amiket az admin felület ellenőriz, és a szolgáltatásfiók saját bind_password-je is ezen a kapcsolaton mennek át. Az a címtár, amelyik a TLS-t a sima porton szolgálja, ugyanazt a hostot kapja egy ldap:// url-lel a 389-es porton és start_tls: true-val. A tls_ca_file csak saját CA-hoz kell — elhagyva a gép rendszer-trustja dönt —, és ha a url nem nevet, hanem IP-címet hordoz, a tanúsítványnak IP-SAN-ra van szüksége. Ha a címtár egyáltalán nem tud TLS-t, az allow_plaintext: true a kimondott — és hangosan jelentett — útja annak, hogy mégis elinduljon; a teljes szabályt a hozzáférési modell írja le.

Az approver_group azt a csoportot nevezi meg, amelynek tagjai eldönthetik a jóváhagyási kéréseket. Ha mellé az approver_group_required: true is bekerül, a hiányzó identitásforrás vagy a hiányzó csoportnév megengedő átcsúszásból kemény konfigurációs hibává válik — érdemes megtenni, amint a csoport tényleg létezik és karban van tartva. Ugyanez a minta rendelkezésre áll a többfaktoros visszaállítás kapujához és a CA-adminisztráció kapujához is; minden kulcsot a konfigurációs referencia sorol fel.

A daemon újraindítása meglévő ldap.yaml-lal űrlapos bejelentkezésre kapcsolja az admin felületet. Ahol nincs elérhető címtár, ott az állapotgyökérben lévő users.json a tartalék identitásforrás.

Ha a szervezetnek van OIDC identity providere, az sso.yaml magát a belépést átadhatja neki — az admin felület böngészős belépését, és az SSH-s átjárós bejelentkezést a device flow-val. Ettől a címtár nem lesz opcionális: a név, amit a provider visszaad, csak kikeresésre kerül benne, és az a név, amit a címtár nem ismer, elutasításra kerül. A kulcsokat a konfigurációs referencia sorolja fel.

Tovább: SSH-célgép vagy webes konzol

Az átjáró most már tudja, kik a felhasználói. Hogy mit érnek el rajta át, az kétféle lehet, és mindkettőnek saját rövid útja van:

Egy célgép SSH-n — egy szerver előkészítése és az első munkamenet: első SSH-munkamenet.
Egy webes konzol — a Grafana, a Prometheus vagy egy BMC webes felülete ugyanazon belépés mögé: egy apps.yaml egy alkalmazással, egy DNS-név hozzá és egy listener-tanúsítvány, az alkalmazások beállítása szerint; a kérés útja a hogyan működik a Web Access lapon áll.

Ellenőrzés

A telepítés:

isg system check

Minden ismert konfigurációs fájlt ellenőriz — létezés, szintaxis, és ahol van ilyen, a fájl saját betöltője —, és élő kapcsolatot szondáz mindenhez, amivel ez az átjáró beszélni van konfigurálva. Nem-nulla kóddal lép ki, ha bármelyik sor elbukik, tehát közvetlenül beköthető cronba vagy egy külső monitorba. A --verbose megmutatja az egyes élő ellenőrzések mögötti allépéseket, és soronként a kikötést is: azt, amit az az ellenőrzés nem mért.

A webUI Rendszerállapot oldala: minden ellenőrzés az állapotával (OK vagy WARN) és a részleteivel, köztük azzal, amit az ellenőrzés nem mér

Képernyőkép: referencia-környezet (env1), 2026-10-17.

A futó daemon, ha a diag.yaml-ban enabled: true áll:

curl http://127.0.0.1:8767/healthz
ok

A /healthz csupasz életjel — nincs függőség-ellenőrzés, nincs fájlolvasás, és sosem hitelesített, mert egy szondát nem szabad token vagy olyan függőség mögé zárni, ami épp maga lehet a leállt dolog. A mellette futó /readyz a függőségek egészségét jelenti, a /metrics pedig a Prometheus-regisztert teszi közzé; mindkettő figyelembe veszi az auth_token-t, ha a diag.yaml beállít egyet.

Egy munkamenet — SSH vagy Web Access — ott van az admin felületen a https://<gateway>:8765/ címen, és az audit.log-ban is, eseményenként egy sorként. Az auditnapló csak hozzáfűzhető, és ez a történtek rekordja; az audit-eseménykatalógus minden eseménynevet felsorol, amit az átjáró kiír, az auditnapló-séma pedig az a szerződés, ami ellen egy naplószállító feldolgoz.

Ez a lap az egygépes út. Flottánál — több bróker egy közös név mögött — az első belépés kliensoldala (a @cert-authority sor, a webUI tanúsítványa, a böngészős komponensek) a flotta-telepítés lap utolsó szakasza.