Basic Gitea Information
Struttura di base
La struttura di base dell'ambiente Gitea consiste nel raggruppare i repository per organizzazione(i), ognuna delle quali può contenere diversi repository e diversi team. Tuttavia, nota che proprio come su github gli utenti possono avere repository al di fuori dell'organizzazione.
Inoltre, un utente può essere membro di diverse organizzazioni. All'interno dell'organizzazione l'utente può avere diverse autorizzazioni su ciascun repository.
Un utente può anche far parte di diversi team con diverse autorizzazioni su diversi repository.
Infine, i repository possono avere meccanismi di protezione speciali.
Autorizzazioni
Organizzazioni
Quando viene creata un'organizzazione viene creato un team chiamato Proprietari e l'utente viene inserito al suo interno. Questo team fornirà accesso amministrativo sull'organizzazione, tali autorizzazioni e il nome del team non possono essere modificati.
Gli amministratori dell'organizzazione (proprietari) possono selezionare la visibilità dell'organizzazione:
Pubblica
Limitata (solo utenti con accesso)
Privata (solo membri)
Gli amministratori dell'organizzazione possono anche indicare se i responsabili del repository possono aggiungere e/o rimuovere l'accesso per i team. Possono anche indicare il numero massimo di repository.
Quando viene creato un nuovo team, vengono selezionate diverse impostazioni importanti:
Viene indicato i repository dell'organizzazione ai quali i membri del team potranno accedere: repository specifici (repository in cui il team è aggiunto) o tutti.
Viene anche indicato se i membri possono creare nuovi repository (il creatore otterrà l'accesso amministrativo ad esso)
Le autorizzazioni che i membri del repository avranno:
Accesso Amministratore
Accesso Specifico:
Team e Utenti
In un repository, l'amministratore dell'organizzazione e i responsabili del repository (se consentito dall'organizzazione) 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 consentendo al relativo 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 l'invio di commit senza firma.
Token di Accesso Personale
Puoi generare un token di accesso personale per dare a un'applicazione accesso al tuo account. Un token di accesso personale fornisce pieno accesso al tuo account: http://localhost:3000/user/settings/applications
Applicazioni Oauth
Proprio come i token di accesso personale, le applicazioni Oauth avranno accesso completo al tuo account e ai luoghi in cui il tuo account ha accesso perché, come indicato nella documentazione, gli ambiti non sono ancora supportati:
Chiavi di Deploy
Le chiavi di deploy potrebbero avere accesso in sola lettura o in scrittura al repository, quindi potrebbero essere interessanti per compromettere repository specifici.
Protezioni del Branch
Le protezioni del branch sono progettate per non dare il controllo completo di un repository agli utenti. L'obiettivo è porre diversi metodi di protezione prima di poter scrivere codice in un branch.
Le protezioni del 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 repository.
Diverse protezioni possono essere applicate a un branch (come a master):
Disabilita Push: Nessuno può fare push su questo branch
Abilita Push: Chiunque con accesso può fare push, ma non force push.
Whitelist Restricted Push: Solo utenti/team selezionati possono fare push su questo branch (ma senza force push)
Abilita Whitelist Merge: Solo utenti/team in whitelist possono fare merge delle PR.
Abilita controlli di stato: Richiede che i controlli di stato passino prima del merge.
Richiedi approvazioni: Indica il numero di approvazioni richieste prima che una PR possa essere fusa.
Limita approvazioni ai whitelisted: Indica utenti/team che possono approvare le PR.
Blocca il merge su recensioni rifiutate: Se vengono richieste modifiche, non può essere fuso (anche se gli altri controlli passano)
Blocca il merge su richieste di recensione ufficiali: Se ci sono richieste di recensione ufficiali, non può essere fuso
Ignora approvazioni obsolete: Con nuovi commit, le vecchie approvazioni verranno ignorate.
Richiedi Commit Firmati: I commit devono essere firmati.
Blocca il merge se la pull request è 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 le credenziali di un utente, i repository potrebbero essere protetti evitando che tu possa inviare codice a master ad esempio per compromettere il pipeline CI/CD.
Last updated
