Rolurile la GuestGet#

GuestGet este compania; tot ce mai există pe acest host este moștenire care va dispărea. Pagina aceasta este catalogul de roluri: ce înseamnă un rol în fiecare sistem la care ajunge o persoană, astfel încât „adaugă un developer” sau „angajăm un om pe suport” să fie o decizie luată o singură dată, aici, și executată de mecanismele din authentik/ (directorul, Cloudflare Access, GitLab, PostgreSQL, sv1, e-mailul) și de back-office-ul platformei (admin.guestget.com).

Două reguli fac catalogul să funcționeze și la 3 oameni, și la 30:

Rolurile sunt funcții, nu titluri. Un CTO este o persoană din infra, tech-leads și management; titlul este treaba resurselor umane, rolul este un set de permisiuni. O persoană are mai multe roluri; un rol nu conține niciodată numele unei persoane.
Înțelesul unui rol stă aici și în cod; cine îl are este o operațiune. Schimbarea a ceea ce poate face support este un merge request pe depozitul acesta sau pe guestget, revizuit. Să-i dai Anei rolul support înseamnă două clicuri în interfața directorului (https://id.profuse.ro/if/admin → Directory → Users, apoi Groups), lucru pe care rolul people îl poate face fără să atingă git-ul. Toate celelalte sisteme citesc asta: Access din claim-ul groups la următoarea ei autentificare, SSSD și PostgreSQL prin LDAP, GitLab în cinci minute, e-mailul în cincisprezece. Nimeni nu dă acces de mână în vreunul dintre sistemele acelea; revizia trimestrială (access-review.md) este cea care prinde excepția care scapă.

Catalogul#

Grupurile sunt slug-uri: ele devin cn-ul din LDAP, grupul Unix, valoarea din claim-ul groups. Fiecare rol are un proprietar, care aprobă apartenența și răspunde pentru ea la revizie.

rolul (grupul)	cine	proprietar
`infra`	operează producția: platformă / SRE și CTO-ul	CTO
`tech-leads`	seniorii care integrează, lansează și citesc date din producție	CTO
`developers`	ingineri backend, frontend, mobile	CTO
`qa`	testeri, automatizare de teste	CTO
`product`	product manageri, designeri	CEO
`support`	suport L1/L2, customer success, implementare	head of customer
`finance`	facturare, facturi, decontări, contabilitate	CEO
`sales`	account executives, parteneriate (agenți afiliați)	CEO
`marketing`	site, blog, conținut, campanii	CEO
`people`	resurse umane și administrativ: primirea oamenilor, plecarea lor, oamenii din director	CEO
`management`	CEO-ul și oricine are nevoie de imaginea întreagă, doar în citire	CEO

Nu adăuga cto, ceo, senior-*, junior-*. Vechimea este un titlu. Dacă un senior are nevoie de mai mult decât un mid, acel „mai mult” este un rol (tech-leads), iar mid-ul îl primește în ziua în care i se acordă încrederea.

La ce ajunge fiecare rol#

Accesul are trei niveluri (onboarding.md): doar identitatea (orice dispozitiv); identitatea pe un dispozitiv administrat (WARP pornit, verificarea stării dispozitivului); identitatea, dispozitivul și rețeaua privată (SSH, bazele de date).

sistemul	infra	tech-leads	developers	qa	product	support	finance	sales	marketing	people	management
administrarea directorului (`/if/admin`)	citire + outposts (dispozitiv)	—	—	—	—	—	—	—	—	adaugă și mută oameni (dispozitiv)	—
contul Cloudflare, Zero Trust	membru	—	—	—	—	—	—	—	—	—	—
sv1 SSH + sudo	da (rețea)	—	—	—	—	—	—	—	—	—	—
PostgreSQL producție	citire/scriere (rețea)	doar citire (rețea)	—	—	—	—	—	—	—	—	—
PostgreSQL staging	citire/scriere	citire/scriere	doar citire	doar citire	—	—	—	—	—	—	—
manualul `handbook.guestget.com` (pagina aceasta, primirea, plecarea, revizia; primele trei și în română, la `/ro`)	da	da	da	da	da	da	da	da	da	da	da
manualul `/who-has-what` (nume și roluri)	da	—	—	—	—	—	—	—	—	da	da
grupul GitLab `guestget` (produsul)	owner	maintainer	developer	developer	reporter	reporter	—	—	reporter	—	reporter
grupul GitLab `profuse` (depozitul acesta: infrastructura și sursa catalogului)	owner	maintainer	reporter	reporter	reporter	reporter	—	—	reporter	reporter	reporter
Sentry	admin	admin	member	member	member	member	—	—	—	—	—
Zabbix, Traefik, administrarea mailcow	da (dispozitiv)	Zabbix, citire (dispozitiv)	—	—	—	—	—	—	—	—	—
aplicația de staging	da	da	da	da	da	da	da	da	da	—	da
back-office `admin.guestget.com` (rolul din platformă)	`super_admin`	`super_admin`	—	—	`product`	`support`	`finance`	`sales`	`content`	—	`management`
administrarea portalului de afiliați (agenți)	da	—	—	—	—	vede	plătește	administrează, impersonează	—	—	vede
e-mail: căsuța personală `first@guestget.com`	da	da	da	da	da	da	da	da	da	da	da
e-mail: adresele comune (vezi mai jos)	security@	—	—	—	—	support@, hello@	billing@	sales@, partners@, hello@	press@	jobs@, hr@	legal@
adăugarea și mutarea oamenilor (interfața directorului)	—	—	—	—	—	—	—	—	—	da	—

Citește-l pe coloane: angajarea unui om pe suport = groups = ["support"] = manualul, aplicația de staging, back-office-ul cu rolul de platformă support, Sentry ca member, GitLab ca reporter (ca să deschidă bug-uri), o căsuță de e-mail și support@ / hello@ în inbox-ul lui. Nimic altceva și nimic de ținut minte.

Două rânduri merită citite de două ori. Manualul este al tuturor: este pagina aceasta, pagina de început și restul lui docs/, publicat la handbook.guestget.com și păzit de nimic altceva decât o identitate din director, deci nimeni nu are nevoie de cont în altă parte ca să citească cum funcționează compania. Singura lui pagină restricționată, /who-has-what, este lista nominală — care persoană are care rol — generată din director și deschisă pentru infra, people și management, cele trei roluri care administrează apartenența, răspund pentru ea și dau socoteală pentru ea. GitLab stă exact invers: acolo se construiește produsul, iar finance și sales nu mai au cont acolo. Au avut unul dintr-un singur motiv — iconița „Start here” trimitea în depozit, deci prima lor zi era un zid de autentificare — iar publicarea manualului a scos motivul.

Manualul este în două limbi#

Tot ce se scrie în depozitul acesta este în engleză, iar docs/ro/ este singura excepție. Motivul este pentru cine sunt scrise: un runbook este citit de oamenii care întrețin sistemele, iar manualul acesta este citit de toți cei pe care îi angajează compania. Paginile de care are nevoie un coleg ca să intre în companie, să înțeleagă cum merge și să plece — onboarding.md, catalogul acesta și offboarding.md — sunt traduse și se citesc la handbook.guestget.com/ro. Fiecare pagină are pe ea linkul către ea însăși în cealaltă limbă.

Două pagini rămân în engleză și fiecare scrie asta acolo unde ar fi fost versiunea ei în română:

revizia trimestrială (access-review.md) este o procedură pe care o face cineva din infra, iar tot ce iese din ea — issue-ul, merge request-ul, ce afișează comenzile pe care ți le cere să le citești — este oricum în engleză;
lista nominală (/who-has-what) înseamnă nume, nume de utilizator și slug-uri de grupuri, care se scriu la fel în orice limbă, iar adresa ei este exact ce potrivește politica din Access. O copie la altă adresă ar fi aceeași listă de nume, fără nicio poartă în față.

Engleza este originalul, și nu doar prin convenție: fiecare fișier în română reține sha256-ul fișierului englezesc din care a fost tradus, iar scripts/build-handbook.py oprește construcția site-ului atunci când cele două nu mai coincid, numind fișierul și comanda care înregistrează noul hash. Prin urmare, o modificare pe o pagină în engleză strică pipeline-ul până când cineva duce schimbarea și dincolo — și tocmai asta se urmărește.

Unde se execută fiecare corespondență#

sistemul	mecanismul
directorul însuși	două roluri în `authentik/rbac.tf`: `directory-people` (creează o persoană, îi resetează parola, o mută între roluri) pentru `people`, `directory-operations` (citește tot, pornește outposts) pentru `infra`. Niciun grup nu este superutilizator; `akadmin`, care nu este o persoană, este contul de urgență, iar orice schimbare de structură este un apply de OpenTofu
Access, WARP, SSH, gateway-ul bazelor de date	un grup Access pentru fiecare rol, pe claim-ul `groups` (`cloudflare/accounts/profuse/access.tf`), o politică pentru fiecare nivel; reguli de Gateway pentru fiecare rol la bazele de date (`gateway.tf`)
rolurile din PostgreSQL	`pg-directory-sync` (sv1, la fiecare 5 minute): infra citire/scriere peste tot; tech-leads doar citire pe prod, citire/scriere pe staging; developers și qa doar citire pe staging; o retrogradare înseamnă o revocare
manualul	`docs/` generat de `scripts/build-handbook.py` și publicat pe Cloudflare Pages de jobul `handbook:deploy`, la fiecare schimbare pe `main`; o aplicație Access pentru site (`directory_everyone`) și încă una pentru `/who-has-what*`, pe care o cale mai specifică o pune înaintea celeilalte. Lista nominală este citită din API-ul directorului la construirea site-ului, iar o programare zilnică o reconstruiește. Paginile în română sunt `docs/ro/`, publicate sub `/ro`; fiecare reține hash-ul sursei ei englezești, iar construcția eșuează când cele două se depărtează (`--refresh-translation-hashes` îl înregistrează pe cel nou)
GitLab	`gitlab-directory-sync` (sv1, la fiecare 5 minute): contul se creează înainte de prima autentificare, cel mai înalt rol stabilește nivelul de acces pe `guestget` și pe depozitul acesta, iar cine pleacă este blocat și scos din amândouă. `finance` și `sales` nu primesc cont
Sentry	SAML prin Access, rolurile Sentry pe aplicația SaaS; rolul din Sentry este member implicit, adminii se pun de mână (sunt trecuți în revizie)
Zabbix	SAML prin Access, pe un dispozitiv administrat, pentru infra și tech-leads; rolul din Zabbix vine din claim-ul `groups` (infra → superadmin, tech-leads → user)
sv1	SSSD `simple_allow_groups = infra`, sudoers `%infra`
e-mail	o căsuță pentru fiecare persoană activă (șablon mailcow, la primul SSO); adresele comune sunt alias-uri ai căror destinatari sunt membrii rolului, puse la punct de `mailcow-directory-sync` (la fiecare 15 minute)
back-office	astăzi: `is_super_admin` + o coloană `platform_role` cu patru drepturi de agent, autentificare cu parolă, fără SSO — vezi secțiunea următoare

Back-office-ul este gaura#

admin.guestget.com este locul în care support, finance, sales și product își vor petrece ziua și este singurul sistem care nu cunoaște directorul: oamenii se autentifică cu parolă, coloana platform_role poate fi pusă doar dintr-un seeder, iar fiecare secțiune în afară de agenții afiliați este doar pentru super-admin. Trei schimbări, în guestget, în ordinea aceasta:

SSO. Oamenii intră în back-office prin authentik (OIDC; Access păzește deja hostname-ul). Autentificarea cu parolă rămâne doar pentru super-adminul de urgență pus din seeder. Claim-ul groups este citit la fiecare autentificare și stabilește platform_role — coloana devine o copie a directorului, niciodată editată de mână.
Un catalog de roluri de platformă care se potrivește cu pagina aceasta. config/platform.php crește de la patru drepturi de agent la secțiuni: organizations.view, organizations.manage, users.view, bookings.view, subscriptions.*, invoices.*, agents.*, content.* (blog, landing, site-uri), analytics.view, impersonate. Roluri: super_admin (infra, tech-leads), support, finance, sales, content (marketing), product, management (citește tot, nu schimbă nimic). Aplicația de admin își condiționează deja navigarea pe drepturi; crește doar harta.
Impersonare cu un motiv. Un om de pe suport care impersonează un hotel este cel mai sensibil lucru pe care îl face compania. Astăzi asta cere super-admin și nu lasă în urmă niciun motiv. Devine un drept al rolului support, care cere referința unui tichet, ține o oră, este doar în citire dacă rolul nu spune altfel și se scrie în jurnalul de audit al adminului împreună cu motivul — exact forma pe care o are deja impersonarea agenților afiliați.

E-mailul#

Un singur domeniu, guestget.com. O persoană are exact o căsuță, firstname@guestget.com, creată de director la prima ei autentificare prin SSO și oprită în ziua în care pleacă. Nimeni nu are o a doua parolă pentru e-mail: clienții folosesc parole de aplicație.

Adresele comune sunt alias-uri, nu căsuțe: support@, hello@, billing@, sales@, partners@, press@, jobs@, hr@, legal@, security@. Destinatarii lor sunt membrii unui rol, ținuți la zi din director — intri în support și support@ ajunge în inbox-ul tău, ieși și dispare, iar o parolă comună nu există niciodată. Astăzi support@, billing@, legal@ și app@ sunt căsuțe adevărate, cu parolele lor; mailcow-directory-sync raportează ce ar deveni fiecare și nu convertește niciodată o căsuță de capul lui — șterge căsuța (după ce o exporți) și rularea următoare creează alias-ul. app@ / noreply@ / alerts@ rămân căsuțe: ele sunt expeditorii și destinatarii platformei înseși, cu parole de aplicație ținute în seiful de secrete, nu de o persoană. Când suportul nu mai încape într-un inbox, un instrument de helpdesk preia support@ — alias-ul doar arată în altă parte.

Numele și domeniul#

Numele de utilizator sunt firstname (sau firstname.lastname la prima coliziune), cu litere mici, alese o singură dată: același șir este handle-ul de GitLab, rolul din PostgreSQL, utilizatorul Unix și căsuța de e-mail. E-mailul din director este adresa @guestget.com a persoanei.

Directorul, GitLab și domeniul echipei din Access poartă încă numele profuse.ro, de la compania care le-a construit. Ele se mută pe id.guestget.com, git.guestget.com și pe o echipă Zero Trust guestget printr-o migrare de sine stătătoare — DNS, certificate, URL-urile de callback OIDC, reînrolarea în WARP — după ce rolurile de mai sus sunt puse la punct, nu înainte: o redenumire cu trei roluri este o dimineață, o redenumire în mijlocul angajărilor este o săptămână.

Cum crește#

Astăzi: catalogul acesta în git, oamenii în interfața directorului, revizia trimestrială.
Când cineva începe să ceară acces în loc să îl primească: fluxul de cerere de acces din authentik (2026.8) lasă o persoană să ceară un rol, iar proprietarul rolului să îl aprobe în portal, cu acordarea consemnată acolo, nu într-o discuție.
Când va exista un sistem de resurse umane: el alimentează directorul prin SCIM și dispar și cele două clicuri. Catalogul nu își schimbă forma la nicio dimensiune; se schimbă doar cine face atribuirea.