Basic Gitea Information
Struttura di base
La struttura di base dell'ambiente Gitea è quella di raggruppare i repo per organizzazione(i), ognuna delle quali può contenere diversi repository e diversi team. Tuttavia, nota che proprio come in github, gli utenti possono avere repo al di fuori dell'organizzazione.
Inoltre, un utente può essere un membro di diverse organizzazioni. All'interno dell'organizzazione, l'utente può avere diverse autorizzazioni su ciascun repository.
Un utente può anche essere parte di diversi team con diverse autorizzazioni su diversi repo.
E infine, i repository possono avere meccanismi di protezione speciali.
Autorizzazioni
Organizzazioni
Quando un'organizzazione viene creata, viene creato un team chiamato Owners e l'utente viene inserito al suo interno. Questo team darà accesso admin sull'organizzazione, tali autorizzazioni e il nome del team non possono essere modificati.
Org admins (proprietari) possono selezionare la visibilità dell'organizzazione:
Pubblica
Limitata (solo utenti con accesso)
Privata (solo membri)
Org admins possono anche indicare se gli admin dei repo possono aggiungere o rimuovere accesso per i team. Possono anche indicare il numero massimo di repo.
Quando si crea un nuovo team, vengono selezionate diverse impostazioni importanti:
Viene indicato ai repo dell'org a cui i membri del team potranno accedere: repo specifici (repo a cui il team è aggiunto) o tutti.
Viene anche indicato se i membri possono creare nuovi repo (il creatore otterrà accesso admin a esso)
Le autorizzazioni che i membri del repo avranno:
Accesso Amministratore
Accesso Specifico:
Team e Utenti
In un repo, l'org admin e gli admin dei repo (se consentito dall'org) possono gestire i ruoli assegnati ai collaboratori (altri utenti) e ai team. Ci sono 3 possibili ruoli:
Amministratore
Scrittura
Lettura
Autenticazione Gitea
Accesso Web
Utilizzando nome utente + password e potenzialmente (e raccomandato) un 2FA.
Chiavi SSH
Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa chiave privata di eseguire azioni per tuo conto. http://localhost:3000/user/settings/keys
Chiavi GPG
Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che tu venga scoperto per aver inviato commit senza una firma.
Token di Accesso Personali
Puoi generare un token di accesso personale per dare accesso a un'applicazione al tuo account. Un token di accesso personale fornisce accesso completo al tuo account: http://localhost:3000/user/settings/applications
Applicazioni Oauth
Proprio come i token di accesso personali, le applicazioni Oauth avranno accesso completo al tuo account e ai luoghi a cui il tuo account ha accesso perché, come indicato nella documentazione, gli scope non sono ancora supportati:
Chiavi di distribuzione
Le chiavi di distribuzione possono avere accesso in sola lettura o in scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici.
Protezioni dei Branch
Le protezioni dei branch sono progettate per non dare il controllo completo di un repository agli utenti. L'obiettivo è mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un certo branch.
Le protezioni dei branch di un repository possono essere trovate in https://localhost:3000/<orgname>/<reponame>/settings/branches
Non è possibile impostare una protezione del branch a livello di organizzazione. Quindi tutte devono essere dichiarate su ciascun repo.
Diverse protezioni possono essere applicate a un branch (come a master):
Disabilita Push: Nessuno può pushare su questo branch
Abilita Push: Chiunque abbia accesso può pushare, ma non forzare il push.
Whitelist Restricted Push: Solo utenti/team selezionati possono pushare su questo branch (ma non forzare il push)
Abilita Merge Whitelist: Solo utenti/team in whitelist possono unire PR.
Abilita controlli di stato: Richiedi che i controlli di stato passino prima di unire.
Richiedi approvazioni: Indica il numero di approvazioni richieste prima che una PR possa essere unita.
Restrict approvals to whitelisted: Indica utenti/team che possono approvare PR.
Blocca unione su revisioni rifiutate: Se vengono richieste modifiche, non può essere unita (anche se gli altri controlli passano)
Blocca unione su richieste di revisione ufficiali: Se ci sono richieste di revisione ufficiali non può essere unita
Annulla approvazioni obsolete: Quando ci sono nuovi commit, le approvazioni vecchie saranno annullate.
Richiedi Commit Firmati: I commit devono essere firmati.
Blocca unione se la richiesta di pull è obsoleta
Modelli di file protetti/non protetti: Indica modelli di file da proteggere/non proteggere contro le modifiche
Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, i repo potrebbero essere protetti impedendoti di pushare codice su master ad esempio per compromettere il pipeline CI/CD.
Last updated
