GitLab Secrets Manager

Agenti più precisi, costi dei token ridotti
Scopri come rafforzare la tua software factory e consentire agli agenti IA di acquisire autonomia senza compromettere la sicurezza.
Scopri tutte le ultime funzionalità e i miglioramenti di GitLab.
GitLab Secrets Manager
Metti fine alla proliferazione dei segreti con GitLab Secrets Manager, basato su OpenBao. I segreti di pipeline e tempo di esecuzione vengono letti da un unico archivio e gestiti con le stesse autorizzazioni e lo stesso audit trail che già proteggono il tuo codice.
Gestisci i segreti dove chi sviluppa lavora già
Con GitLab Secrets Manager, i segreti risiedono negli stessi gruppi e progetti del codice che li utilizza. Richiederne uno si integra quindi nel normale flusso di lavoro, senza plug-in, agenti o altri strumenti da imparare a usare.
L'accesso segue la gerarchia esistente di gruppi e progetti e le autorizzazioni granulari offrono un controllo maggiore, quindi non c'è un secondo modello di accesso da sincronizzare. Definisci una credenziale una volta a livello di progetto o condividila in tutto il gruppo. Chiunque lasci un progetto perde automaticamente l'accesso.
Chi sviluppa dichiara il segreto necessario a un job utilizzando la parola chiave secrets: nel file di configurazione della pipeline. GitLab conosce già il progetto, il ramo e l'ambiente del job, quindi non occorre collegare le identità tra CI e un vault separato.
Quando un riferimento a un segreto non funziona, la correzione viene rilasciata nella stessa richiesta di merge del codice, senza bisogno di un secondo repository o di un'ulteriore approvazione. Con credenziali sicure a portata di mano, meno segreti finiscono nelle variabili CI, nei file di configurazione locali o nel repository.
Limita il raggio d'azione delle credenziali esposte
Quando una dipendenza compromessa viene eseguita in un job, con GitLab Secrets Manager basta ruotare e sottoporre ad audit i segreti a cui il job poteva accedere, senza bloccare tutte le pipeline.
A differenza delle variabili CI, accessibili a tutti i job della pipeline, un segreto è accessibile soltanto ai job che lo dichiarano e rientrano nel suo ambito, definito da ramo, ambiente e stato di protezione.
GitLab Secrets Manager scrive il valore in un file temporaneo ed espone solo il suo percorso, limitando l'esposizione a sottoprocessi, crash dump e telemetria. Il valore viene mascherato nei log dei job ed eliminato al termine del job, quindi nulla persiste sul runner.
Gli eventi di creazione, lettura, aggiornamento ed eliminazione finiscono nello stesso audit trail del resto di GitLab. Le operazioni di lettura della pipeline includono gli ID della pipeline e del job, così chi gestisce gli incidenti e gli auditor possono tracciare una credenziale dall'accesso al deployment senza dover correlare manualmente i log di sistemi diversi.
Un unico archivio per pipeline, cluster e infrastruttura
Le pipeline leggono i segreti direttamente. I carichi di lavoro Kubernetes, le esecuzioni di Terraform e OpenTofu, gli strumenti CLI compatibili con Vault e altre automazioni si connettono tramite punti di integrazione standard, con le stesse autorizzazioni e lo stesso audit trail delle pipeline.
External Secrets Operator mantiene i segreti Kubernetes sincronizzati con GitLab, così i valori aggiornati tramite rotazione si propagano senza un nuovo deployment. Terraform e OpenTofu leggono i segreti come origine dati quando vengono eseguiti, mantenendo le credenziali fuori dai file e dalle variabili CI/CD.
Basato su OpenBao, Secrets Manager espone un'API compatibile con Vault, consentendo ai team che già utilizzano script con la CLI di OpenBao o Vault di mantenere gli stessi comandi. Qualsiasi altra automazione recupera i segreti tramite l'API di Secrets Manager, anziché inserire le credenziali direttamente nel codice o mantenere file di variabili separati.
Le credenziali accompagnano i carichi di lavoro multi-cloud, ibridi e on-premise senza federazione delle identità specifica per ogni piattaforma. Spostare un carico di lavoro su un altro cloud non significa configurare un secondo archivio, e i segreti altrimenti dispersi tra archivi per account e per regione risiedono in un unico posto.
GitLab va oltre la gestione delle credenziali. La protezione push dei segreti impedisce alle credenziali di raggiungere il repository, il rilevamento lato client intercetta i segreti nel testo di ticket e richieste di merge e il rilevamento dei segreti nella pipeline individua quelli già presenti nel codice. GitLab Duo Agent Platform esegue la valutazione delle vulnerabilità rilevate e segnala i probabili falsi positivi.
GitLab Secrets Manager è un componente aggiuntivo a pagamento per Premium e Ultimate, fatturato tramite Crediti GitLab: 1 credito per ogni segreto archiviato al mese e 1 credito ogni 2.500 operazioni di lettura dei segreti. Se preferisci una tariffa fissa, è disponibile un contratto di licenza Enterprise (ELA).
// PRENDI IL CONTROLLO DEL FUTURO
Sei già cliente Premium o Ultimate? Puoi provare GitLab Secrets Manager gratuitamente per 30 giorni o fino all'esaurimento di 500 crediti di valutazione, a seconda dell'evento che si verifica per primo.
GitLab ha costruito questo framework di maturità grazie al lavoro svolto con clienti leader del settore. Rispondi ad alcune domande su come il tuo team gestisce la sicurezza e la conformità per ottenere il tuo punteggio di maturità e ricevere consigli per la fase successiva.
Il quiz dura 5 minuti o meno
Continuano a funzionare e nulla viene migrato automaticamente. Le variabili CI/CD rimangono una soluzione valida per le configurazioni non sensibili. Per trovare i candidati alla migrazione, utilizza lo strumento di audit dei segreti per le variabili CI/CD per identificare quali variabili contengono credenziali, quindi sposta tali valori in GitLab Secrets Manager secondo i tuoi tempi.
Sì, restano invariate. Le integrazioni esistenti con Vault di HashiCorp, AWS Secrets Manager, Azure Key Vault e Google Clou