È male usare il sudo di Jenkins?

Uso il plug- in Pubblica su SSH per distribuire le mie app Jenkinsin ambienti diversi. Alcuni processi di distribuzione eseguono preparazioni ambientali e cose come l'arresto e il riavvio del servizio di sistema del server delle app. Alcuni di questi comandi richiedono sudo.

Sono solo curioso di sapere se può essere una cattiva pratica di sicurezza richiedere sudo in lavori di pubblicazione ed esecuzione remoti su Jenkins. Dovremmo modificare la politica di sicurezza sull'host di destinazione per consentire l'esecuzione delle funzioni richieste senza sudo?

No, in realtà è davvero una buona pratica di sicurezza fare sudo quando hai bisogno di privilegi di livello superiore. Questo è il motivo per cui la maggior parte delle distribuzioni proibiscono l'accesso predefinito e in realtà ti costringono a sudo suinvece di digitare semplicemente su: vogliono incoraggiarti a usare sudo per i suoi vantaggi di sicurezza. Ci sono alcuni motivi per cui:

• Revisione. Quando sudo, il sistema registra chi ha eseguito la sudo e il comando che ha eseguito. Questo aggiunge molto forense quando è necessario tornare indietro e capire cosa è successo - assegnare la colpa, catturare attività nefaste o solo per scopi di risoluzione dei problemi (cosa diavolo è successo ieri sera alle 19:00 prima che questo server diventasse AWOL?)

• Regole del Sudo. Solo perché un utente deve eseguire qualcosa con i privilegi in scala non significa che deve eseguire tutto con i privilegi in scala. L'uso di su o l'aggiunta di un utente alla ruota consente all'utente di fare tutto . Con sudo, tuttavia, è possibile specificare ciò che gli utenti possono e non possono fare utilizzando gli alias di comando che consentono l'uso di caratteri jolly, consentendo in tal modo regole flessibili che garantiscono agli utenti i privilegi di utilizzare alcuni comandi, ma non altri.

• Tempra. È possibile disabilitare il root. Come in tutti gli effetti, non esiste ed è utile / utilizzabile solo in modalità utente singolo, che richiede il riavvio di un server (e l'unico motivo per cui è consentito è il recupero della password). sudo sunon lavora più. Questo viene fatto impostando la shell di root su / bin / nologin. che è un ottimo modo per prevenire molte vulnerabilità di escalation di root. Questo, ovviamente, presuppone che tu stia utilizzando correttamente il punto elenco sopra (e puoi ancora concedere a un utente amministratore specifico tutte le autorizzazioni, sebbene ciò minerebbe la tua posizione di sicurezza).

Queste cose sono, ovviamente, solo una parte del tuo modello di sicurezza. Ad esempio, a meno che non si disponga di utenti con privilegi amministrativi completi (e talvolta anche in quel caso), l'utente potrebbe essere in grado (probabilmente è in grado) di eliminare registri e cronologia, a meno che non si utilizzi un server di registro e un syslog per spedire i registri fuori dalla scatola. Quindi non c'è modo di rimettere quel gatto nella borsa. Naturalmente, se si utilizza una struttura di directory di autenticazione centrale, questo ritorna in gioco: se comprometto un account, viene compromesso su tutti i server dell'organizzazione, incluso probabilmente il tuo log server.

In breve, la sicurezza è complicata, ma sudo è un ottimo strumento per l'architettura di un ambiente sicuro e più persone dovrebbero usarlo al massimo.

Se si consente l' sudoaccesso remoto o remoto a qualcosa che SUID rootha una superficie di attacco abbastanza simile. Vorrei rimanere sudoin catena perché ti consente di limitare facilmente i comandi e ha la registrazione che sarà vitale se devi controllare le cose in seguito. sudoha anche una storia molto più lunga nella produzione. Fare qualcos'altro avrà meno storia e maggiori cambiamenti di spiacevoli sorprese.

Ci sono altre cose che puoi fare per renderlo più sicuro però:

• stringere ssh
• consenti i comandi di riavvio solo per alcuni utenti specifici, incluso uno per jenkins
• consentire l'accesso solo per quegli utenti specifici da tutti gli IP interni o solo da jenkins e IP jump box
• archiviare i registri su caselle remote in modo che non possano essere confusi