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”

Page 1 of 3 | Next page