Gestire le identità nelle istanze cloud distribuite

Ho molte istanze in diversi cloud, anche approfittando di alcune offerte gratuite per sviluppatori: Amazon Web Services (AWS), Digital Ocean, HP Cloud, ma anche cloud regionali come Moresi.Com, Enter o le mie istanze virtuali sui miei sistemi in housing.

Insomma, un bel po’ di sistemi Linux distribuiti nel mondo, forse come molti informatici.  E su questo si incastra il problema di avere la mia identità e quella dei miei utenti/sviluppatori distribuita in questi sistemi. Mentre in una intranet avrei usato LDAP senza esitazioni, creare un LDAP esposto ad Internet potrebbe non essere una buona idea.

Allora come fare a risolvere questo problema e contemporaneamente avere un ottimo livello di sicurezza? La risposta potrebbe essere quella di usare il nuovo modulo NSS per SecurePass.

Fino ad adesso SecurePass è stato sempre usato come un “two factor authentication” nel cloud, soltanto sfruttando la parte di autenticazione nel sistema operativo. Ma la nuova versione beta è in grado di ospitare gli “extended attributes”, che sono informazioni arbitrarie che un amministratore o una applicazione puo’ usare per ogni utente di SecurePass.

Useremo SecurePass per autenticare l’utente e tenere le informazioni Unix atttraverso questa nuova funzionalità. In particolare, useremo:

• il sottosistema PAM per autenticare gli utenti via RADIUS
• il nuvo modulo NSS di SecurePass per ottenere informazioni di UID/GID/….

SecurePass e gli extended attributes

La prossima generazione del servizio SecurePass (attualmente in beta) è in grado di ospitare informazioni arbitrarie per ogni profilo utenti. Questa funzionalità è chiamata “Extended Attributes” (o xattrs) e -come potete immaginare- sono organizzate in modalità chiave/valore.

Dovete avere i SecurePass tools per modificare gli extended attributes di un utente. Le nuove release di Debian Jessie and Ubuntu Vivid Vervet, avranno un pacchetto per questo, quindi potrete fare:

# apt-get install securepass-tools

Per altre distribuzioni Linux (o Unix), potete usare il python package installer (PIP) per installare i tools. Installate come pre-requisito pycurl e poi:

# pip install securepass-tools

Anche se i SecurePass tools hanno la possibilità di avere un file di configurazione locale, per questo tutorial raccomandiamo di creare un file /etc/securepass.conf, in modo da essere usato anche dal modulo NSS. Il file di configurazione e’ simile a quanto sotto:

[default]
app_id = xxxxx
app_secret = xxxx

Dove app_id e app_secrets sono API keys valide per accedere a SecurePass beta.

Attraverso la riga di comando, saremo in grado di impostare UID, GID e tutti gli attributi Unix per ogni utente:

# sp-user-xattrs user@domain.net set posixuid 1000

Mentre  posixuid e’ l’attributo minimo per avere un login su Unix con il modulo NSS, i seguenti attributi sono validi:

• posixuid → UID dell’utente
• posixgid → GID dell’utente
• posixhomedir → Home directory
• posixshell → Shell preferita
• posixgecos → Gecos (il default è lo username)

Installazione e configurazione del modulo NSS SecurePass

Similmente a quanto avviene per i tools, Debian Jessie e Ubuntu Vivid Vervet hanno un pacchetto nativo per SecurePass

# apt-get install libnss-securepass

Per le precedenti releases di Debian e Ubuntu, ma anche per CentOS e RHEL, è sempre possibile installare il modulo. I sorgenti sono disponibili su:

https://github.com/garlsecurity/nss_securepass

Poi:

./configure
make
make install (solo Debian/Ubuntu)

Per CentOS/RHEL/Fedora bisogna installare il modulo NSS nel posto giusto:

/usr/bin/install -c -o root -g root libnss_sp.so.2 /usr/lib64/libnss_sp.so.2
ln -sf libnss_sp.so.2 /usr/lib64/libnss_sp.so.2

Il file di configurazione /etc/securepass.conf va esteso per avere le informazioni di default per il modulo NSS. Bisogna creare una sezione [nss] come da basso:

[nss]
realm = mydomain.com
default_gid = 100
default_home = "/home"
default_shell = "/bin/bash"

Il realm va impostato come quello registrato su SecurePass, il modulo NSS farà append del dominio/realm corrispondente all’utente Unix. Io preferisco impostare il GID corrispondente al gruppo “users”, che di solito su Linux è il gruppo 100. Fate in modo che questo gruppo esista a livello di sistema operativo. Se non si impostano i default su home e shell, i default dei default sono “/home” e “/bin/false”

Dobbiamo ora configurare il Name Service Switch (NSS) per usare SecurePass. Cambiamo il file  /etc/nsswitch.conf aggiungendo “sp” alla riga passwd come segue:

$ grep sp /etc/nsswitch.conf
passwd:   files sp

Controllate che il sottosistema NSS stia funzionando con il modulo SecurePass facendo una query alla tabella passwd come segue:

$ getent passwd user
user:x:1000:100:My User:/home/user:/bin/bash

$ id user
uid=1000(user)  gid=100(users) groups=100(users)

A questo punto abbiamo configurato gli utenti a sistema operativo, ma gli stessi non potranno collegarsi perche’ manca una password corrispondente. Useremo SecurePass per autenticare gli utenti.

Configurare PAM per SecurePass

Se stai usando CentOS o RHEL, bisogna avere EPEL configurato. Per attivare EPEL, seguite le istruzioni su http://fedoraproject.org/wiki/EPEL

La configurazione seguente non è stata provata con SE-Linux abilitato (controllate che sia disabilitato o in modalita’ permissive).

Su CentOS/RHEL, installate il modulo PAM RADIUS con:

# yum -y install pam_radius

Su Debian/Ubuntu, installate il modulo PAM RADIUS con:

# apt-get install libpam-radius-auth

Nota: al momento della scrittura del presente articolo, EPEL 7 è ancora in beta e non contiene il modulo PAM RADIUS. E’ stata fatta una richiesta attraverso il Bugzilla di RedHat per includere questo pacchetto in EPEL 7

Accediamo all’interfaccia di amministrazione SecurePass e aggiungiamo un nuovo device RADIUS. Dobbiamo solo settare l’IP Pubblico del server, un fully qualified domanin name (FQDN) e la secret pass per l’autenticazione Radius. Se siete sotto NAT, questo corrisponde all’IP pubblico di uscita dei pacchetti. Dopo l’aggiunta avremo un piccolo riassunto con i dati del device appena aggiunto. Per questo esempio, useremo “secret”.

Configurate il modulo PAM RADIUS attraverso il file /etc/pam_radius.conf e aggiungete le seguenti righe:

radius1.secure-pass.net secret 3
radius2.secure-pass.net secret 3

Ovviamente “secret” è la stessa che abbiamo impostato attraverso l’interfaccia di amministrazione di SecurePass administration interface. A questo punto bisogna modificare il file di configurazione di PAM.

In CentOS, modificate il file /etc/pam.d/password-auth-ac; in Debian/Ubuntu modificate il file /etc/pam.d/common-auth ed assicuratevi che il modulo pam_radius_auth.so sia nella lista.

auth required pam_env.so
auth sufficient   pam_radius_auth.so try_first_pass
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

Conclusioni

E’ difficile avere a che fare con tante istanze Linux distribuite; ci sono problemi che spaziano dal mantenere il software sempre aggiornato, al logging centralizato fino alla gestione delle utenze. Nel cloud, infatti, non è sempre possibile usare i software che tradizionalmente venivano usati nelle intranet. Alcuni tools, come SecurePass, possono aiutare nella gestione quotidiana.

Per poter accedere alla Beta di SecurePass, bisogna attivare SecurePass su: http://www.secure-pass.net/open

E successivamente mandare una mail a support@secure-pass.net richiedendo l’accesso alla beta.