RoadHouse - Progetto

Ho effettuato alcune configurazioni sul nuovo server RoadHouse. Vertono principalmente su due punti: creazione di container per l'installazione di servizi in ambienti isolati e frontend caching proxy per smistare il traffico web ai vari container.

Struttura

I vari container comunicano in una loro rete interna abbinata all'interfaccia lxcbr0. Il server Varnish riceve le richieste dall'esterno e fa da proxy verso i vari container. I container non sono accessibili direttamente dall'esterno (hanno un ip privato interno)

LXC

LXC (Linux Containers http://lxc.sourceforge.net/ ) è un progetto che permette, utilizzando chroot e le funzionalità del kernel denominate cgroups, di creare degli ambienti di esecuzione totalmente isolati dal resto del sistema. Nel nostro progetto l'idea è di dedicare ad ogni singolo servizio un container separato, in modo da poter procedere in modo indipendente ad aggiornamenti, patch ecc ecc senza impattare sugli altri servizi.

Rete

E' stata creata un interfaccia lxcbr0, un bridge interno alla macchina alla cui rete si collegheranno tutti i container, partecipando alla rete 10.78.88.0/24.

I container hanno accesso all'esterno, attraverso NAT effettuato dal firewall di RoadHouse.

Accesso

L'accesso ai container creati si ha prima collegandosi a RoadHouse e poi effettuando ssh verso l'ip privato del container (TODO: nattare le porte ssh verso l'esterno per evitare questo salto?)

Container attivi

bromuro: sito web di prova
custer: cdimages
mail: ?
spock: gitlab
xpocalypse: progetto xpocalypse

Tools

Le macchine sono create con lo script lxc-debootstrap che a partire da un semplice file di configurazione, crea la macchina a partire da una root creata con debootstrap ed effettuando alcune modifiche per girare in lxc.

Il tool deve essere eseguito da root. Per maggiori informazioni si rimanda al README abbinato.

**da completare** attualmente ho creato dei volumi su file per fare dei container con filesystem limitato. Partito da questo link mounting a file as filesystem e mknod permanent

L'avvio e lo stop delle macchine virtual può essere fatto da root con i comandi che trovate nella guida ufficiale di LXC nel wiki di ubuntu (o qualsiasi altra guida).

Varnish

Varnish è un caching proxy frontend server. Il suo scopo nel progetto sarà di ricevere dall'esterno le connessioni degli utenti e passare le richieste al container appropriato. Inoltre effettuerà caching dei, riducendo quindi la quantità di risorse necessarie specialmente per la riesecuzione di pagine dinamiche (es. php o python) che non sono nel frattempo variate.

Isolamento degli utenti

Gli utenti che dovranno connettersi ai container dovranno prima di tutto collegarsi a roadhouse, poi da li fare ssh verso l'host a cui sono autorizzati. Per evitare di dare un ambiente troppo aperto sulla macchina roadhouse gli utenti saranno isolati in un ambiente ristretto con shel rbash (restricted bash).

L'utente viene creato in questo modo

useradd --comment "Restricted shell user" --shell /bin/rbash --create-home --home-dir /home/newuser newuser

e poi ne viene impostata la password as usual con passwd

Nella home verranno poi cancellati tutti i file contenuti (anche quelli nascosti) e creato una cartella bin e un file .profile.

.profile:

export PATH=$HOME/bin
export PS1="[\u@\h \W]$ "

La cartella bin invece deve essere fatta in questo modo:

mkdir bin
ln -s /usr/bin/ssh bin/ssh
ln -s /usr/bin/ssh-keygen bin/ssh-keygen
ln -s /usr/local/bin/take-my-key bin/take-my-key
# Se serve dare accesso diretto ssh a delle macchine backend (esempio per git) linkare anche nc
ln -s /bin/nc bin/nc

In questo modo i comandi ammessi saranno solo ssh, ssh-keygen e take-my-key

take-my-key

lo script take-my-key non fa altro che copiare la propria chiave pubblica in /keys/username.pub

Distribuzione delle chiavi

Per distribuire le chiavi nei container c'è uno script che si chiama synkeys. La configurazione di questo file è fatta nel file CSV /keys/authorizations con la seguente struttura:

User,server1,server2,server3
remixtj,root,helios,,

dove remixtj e il nome dell'utente roadhouse (con corrispondente chiave /keys/remixtj.pub), e i campi successivi sono l'utente che può impersonare nel server remoto. In questo caso quindi remixtj può loggarsi come: root@server1, helios@server2, nessun accesso al server3.

Una volta eseguito lo script verranno lanciati i relativi comandi ssh-copy-id per allineare le chiavi.

TODO: manca un meccanismo per evitare i duplicati negli authorized_keys remoti, fare in modo che la chiave dell'utente con ci gira synkeys sia distribuita in tutti gli utenti creati nei container (nel template precise.amd64 è già caricata la chiave di root@roadhouse in /root/.ssh/authorized_keys), costruire il file authorizations a partire da una pagina del wiki.