Come proteggere l'utente condiviso sul build server?

Question

Come proteggere l'utente condiviso sul build server?

#1 da (2 voti)
#2 da (0 voti)

5

Abbiamo un server CI installato come build utente e tutte le attività vengono eseguite come quel rispettivo utente a livello di sistema operativo. Abbiamo molti team che condividono il build server, il che significa che build utente e le sue risorse sono condivisi.

Ogni team gestisce anche ambienti diversi e questo richiede la connettività ssh dal server di build. Poiché stiamo guidando l'automazione, la connettività senza password è stata inizialmente configurata per facilitare l'esecuzione di attività automatizzate da remoto (la chiave pubblica dell'utente build è stata copiata nel file deploy di authorized_keys sull'host remoto).

Questo come si può immaginare pone un problema di sicurezza poiché qualsiasi utente che esegue un'attività può accedere a qualsiasi ambiente.

Una soluzione potrebbe essere usare qualcosa come sshpass (fornire la password ssh come argomento) e avere combinazioni utente / password diverse per ogni ambiente. A livello di attività, crea ACL basati su ruoli per bloccare chi può vedere la password come sembra essere in testo normale. Un'altra cosa che mi interessa sapere di più è l'esposizione del comando qui. Sono stato indotto a credere che gli utenti possano sfruttare al massimo il processo in esecuzione e vedere quali comandi è stato eseguito da build dall'utente - è possibile senza i privilegi di root? (ancora meglio se qualcuno può illustrare come questo può essere fatto o indicarmi qualche documentazione)

Oltre a convalidare il mio approccio, sto anche cercando consigli su come questo problema possa essere potenzialmente risolto.

operating-systems access-control ssh

posta kaizenCoder 18.02.2016 - 09:56

fonte

2 risposte

Leggi altre domande sui tag operating-systems access-control ssh

Posso revocare un certificato client usando solo il suo numero di serie (non è crt / pem)? Come disabilitare l'analisi del protocollo conntrack nel kernel di Linux?

score 2 · Answer 1

Se l'account build può eseguire comandi arbitrari come utente di produzione su un server di produzione, sarà necessario bloccarlo. Solo un gruppo selezionato di utenti privilegiati dovrebbe essere in grado di usarlo, idealmente senza la possibilità di modificare i comandi (si spera piccoli set di predefiniti).

Hai davvero bisogno di questa abilità? Forse c'è una soluzione migliore, come un'area di rilascio sui server di produzione a cui l'account build può scrivere, completa di script sui server di produzione che spostano rapidamente il carico utile nell'area appropriata (quindi non viene sovrascritto), estrailo e quindi installalo secondo necessità. L'installazione verrebbe eseguita con un account utente specifico dell'applicazione anziché con un account generico build o deploy .

Quando ho impostato questo tipo di cose in passato, ho fatto un uso copioso di sudo e /etc/sudoers per limitare la capacità dei singoli utenti di agire come qualsiasi account di ruolo (come build ). Ho anche utilizzato aree di rilascio, che in genere erano SFTP o controllo di revisione (sovversione, git, ecc.).

Il controllo delle revisioni è piacevole perché i registri sono più accessibili dei registri sudo . Basta aggiungere un tag e il processo cron eseguito ogni cinque minuti riconoscerà il tag, verificherà l'aggiornamento e darà il via a una nuova build. Il completamento riuscito della build (e di una suite per il test dei fumi) attiva automaticamente l'installazione su un server di staging, dopodiché il team addetto al QA riceve un'e-mail. Quando il QA è contenuto, aggiungono un altro tag di repository e il pacchetto di staging viene installato in produzione.

score 0 · Answer 2

Capisco che risponderò con le mie conclusioni poiché non ho ricevuto risposta.

have been lead to believe that users can peak into the running process and see what commands the build user has executed - is this possible without root privileges? (even better if someone can illustrate how this can be done or point me to some documentation)

Questo è effettivamente possibile con pochissimo sforzo. a ps -ef | grep build mostrerà che i comandi vengono eseguiti come build utente insieme agli argomenti. Ciò significa che le password possono essere esposte a un utente diverso con intenzioni malevole. Anche le variabili d'ambiente possono essere visualizzate tramite /etc/proc .

Più ne leggo più mi viene fatto credere che tutto si riduce alla "fiducia". Un server CI è generalmente configurato per piccoli team. Per favorire la collaborazione viene conferita una certa quantità di fiducia tra i membri del team.

Nel mio caso d'uso sopra, è essenzialmente configurato come server CI generico. Qui abbiamo più team che lo condividono per eseguire attività. Direi che questo rompe il 'modello di fiducia' a meno che non sia possibile fornire una segregazione.

Per farla breve, abbiamo deciso che il server CI sarà sotto il controllo operativo per eventuali modifiche. Questa è certamente una soluzione temporanea per supportare un modello di lavoro condiviso.

In futuro forniremo agenti remoti e li assoceremo per team.