Scegli il livello di collaborazione
Forgejo e Gitea sono esempi di software forge leggero; il semplice Git SSH può bastare per un flusso di lavoro più piccolo. Abbina i requisiti di issue, revisioni, archiviazione dei pacchetti e identità al progetto. Verifica le versioni supportate e le licenze attuali.
Separa le build dalla forge
Un runner CI esegue codice controllato dal progetto e non dovrebbe conservare credenziali illimitate per la forge o per l'host. Isola i runner, limita l'ambito dei token ed evita di eseguire job non attendibili sullo stesso account privilegiato del servizio del repository.
Proteggi l'accesso e la registrazione
Disabilita la registrazione pubblica quando il servizio è privato. Usa account individuali, autenticazione forte e chiavi di deployment con ambito ben definito. Documenta la porta SSH e la chiave host; non abituare silenziosamente gli utenti a ignorare gli avvisi sulla chiave host.
Esegui il backup completo del servizio
I soli repository potrebbero non includere issue, account, allegati e configurazione. Segui la procedura di backup coerente della forge e verifica un ripristino con permessi dei file e segreti dell'applicazione intatti.
Una checklist per il ripristino della forge
Esporta il database in modo coerente e conserva l'archiviazione del repository, gli allegati, l'archiviazione di file di grandi dimensioni se abilitata, la configurazione e i segreti di crittografia. Verifica un clone sul percorso SSH o HTTPS previsto dopo il ripristino. Mantieni la forge e qualsiasi worker CI isolati affinché una build non possa riscrivere la configurazione del servizio stesso.
Mantieni ristretti i diritti di distribuzione
Una chiave di deployment in sola lettura può bastare per un server che si limita a scaricare codice. Un'automazione di rilascio può richiedere un piccolo ambito aggiuntivo. Preferisci chiavi indipendenti per macchine diverse, registrane lo scopo e rimuovile quando la macchina viene dismessa.
Usa il servizio di collaborazione più piccolo adatto
Per pochi repository privati, Git bare su SSH limitato può essere sufficiente. Forgejo o Gitea aggiungono account, pull request, issue e pacchetti opzionali al costo di un database, aggiornamenti dell'applicazione e più stato persistente. Registra quali funzionalità il team userà effettivamente. Preventiva separatamente la crescita dei repository, gli oggetti di grandi dimensioni, gli allegati e gli artefatti di build; il calcolo per la CI può superare quello della forge stessa.
- Scegli un nome HTTPS canonico e proteggi il suo account DNS.
- Decidi se la registrazione è chiusa, su invito o moderata.
- Assegna al servizio forge un'identità non privilegiata e uno storage privato durevole.
Documentazione ufficiale: Installazione del container Forgejo
Separa i percorsi web, SSH e database
Usa la configurazione upstream per la release selezionata e fissa la versione dell'immagine prevista. Un reverse proxy TLS dovrebbe raggiungere il listener web interno; il database dovrebbe essere raggiungibile solo dalla forge. Se Git SSH usa una porta del container, mantieni l'host annunciato e la porta esterna coerenti con la mappatura. Non sostituire né esporre accidentalmente il listener SSH dell'amministratore host mentre modifichi la forge. Chiudi l'accesso all'installazione/configurazione una volta creato il proprietario iniziale.
- Verifica la proprietà del volume persistente prima di avviare l'applicazione.
- Usa un utente del database limitato al database della forge.
- Mantieni i runner CI su un perimetro di fiducia separato, soprattutto per i repository non attendibili.
Documentazione ufficiale: Rete e persistenza Docker di Forgejo
Verifica clone, push e un'operazione negata
Crea un repository privato usa e getta e testa il suo clone HTTPS o SSH URL da un normale account sviluppatore. Esegui il commit e il push di un file innocuo, poi verifica che un altro lettore autorizzato possa recuperarlo. Un account non invitato deve fallire la lettura del repository privato. Controlla la gestione dei file di grandi dimensioni e l'email di notifica, se abilitata. Per le macchine dedicate solo al deployment, verifica che una chiave di sola lettura possa recuperare e non possa fare push; un'autenticazione riuscita da sola non dimostra il confine di autorizzazione previsto.
# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -vRecupera la discussione oltre al repository
Esegui un backup coerente di applicazione/database, archiviazione del repository, allegati, dati LFS, configurazione e segreti di crittografia necessari. Segui la procedura di backup della versione della forge installata; i comandi di backup di Gitea non sono automaticamente intercambiabili con ogni release di Forgejo. Ricostruisci in isolamento e verifica un issue, un allegato, l'accesso e il clone. Se il push fallisce dopo uno spostamento, controlla host/porta SSH, mappatura delle chiavi, autorizzazioni di archiviazione e URL di clone pubblicizzati prima di modificare globalmente le autorizzazioni del repository.
Documentazione ufficiale: Backup e ripristino di Gitea