Docker Swarm: emmascarament de claus i altres secrets

Prerequisits: conèixer Docker i Docker Swarm.

Importancia vital de l'emmascarament

L'emmascarament de claus a nivell d'Administració de Sistemes és de vital importancia. Es un fet demostrat estadísticament, que els atacs amb objectiu de obtenir dades sensibles, es produeix amb més èxit desde l'interior de les organizacións, que no pas desde l'exterior.

Degut a aquest perill, les claus d'accés a serveis d'identificació d'usuaris i cualsevol alta dada considerada secreta, és inconvenient sigui emmagatzemada en clar (es llelleixi directament).

El repte consisteix en mantenir organitzada la informació i continguda dintre de l'àmbit adient.

El problema moltes vegades, es que sengon la sensibilitat o interés de una persona o grup, una clau privada por ser de domini públic fàcilment.

Un altre problema similar són els paràmetres de crida a processos, que per deducció aporten molta informació al atacants de sistemes. El atacants poden ser molts i organitzats, sient preparats per la seva particular inauguració; El mateix dia de posta en producció d'un entorn productiu públic pot patir atacs-de-dia-cero, degut principalment a la visibilitat de paràmetres i deficiencia en l’emmascarament de secrets.

En l'entorn d'ensenyament aixó por esdevenir en que un alumne perdi la privacitat d'accés al seu espai cloud, que un profesor tingui seguidors anònims del seu treball (especialment d'exàmens que prepara) o qualsevol altre alteració de l’àmbit al què pertany una l'informació. En en menys d'un any lectiu, un equip d'ensenyament, pot trobar-se directa o indirectament, amb aquesta varietat de casos (exemples amb justificacions):

Alumnes en defensa de les seves qualificacions.

• Alumn@ capaç de llegir el teclat en el moment d'introduir una contrasenya.
• Alumn@ entra en compte d'un altre i esborra part de la seva informació al cloud.
• Alumn@ fa servir contrasenya per suplantar identitat d'un professor/a enviant eMails malèfics inclus a alumn@s.
• Alumn@ de primer de cicle, acumula en el seu espai al núvol entregues de companys i a mes ja té en el seu poder documents de cursos superiors, per fer servir en el futur.
• Alumn@s de cicle superior organitzats, cadascú amb el seu rol, per accedir periòdicament a l'ordinador del profe i als recursos. Rols tipus:
• Un alumn@ vigila el canvi de prof@ al passadís.
• Altre proveeix sistema de copia (pendrive, disc extern).
• Altre desbloqueja amb usuari genèric el PC d'aula, que es un element compartit. Pot ser inclùs han escalat permisos en aquesta màquina clau, donat és sempre al seu abast.

Els objectius son clars:

• Activitats que es preparem en calent a l'aula.
• Activitats que corregim (en general, donat qualsevol informació del PC del prof@ es d'un ambit superior).
• Promoure l'intercanvi d'informacions a canvi d'altres informacions o bens no quantificables de tota índole.

Prof@s en defensa de l'educació dels alumn@s.

• Hem d'anar d'un aula a l'altre, en temps record (5 minuts).
• Deixem esporàdicament l'ordinador d'aula engegat, pel pròxim profe.
• Eventualment oblidem el nostre cloud connectat.
• Eventualment no bloquegem el nostre terminal i marxem.
• La sensibilitat de les dades que manegem es alta, però el medi ni l'entorn faciliten la protecció (Aquí n'hi ha molta feina pendent en l'àmbit de direcció d'ensenyament).

¿Que esdevé quan un curs docent termina?

Una ingent quantitat d'informació de persones, proves avaluatòries i material docent son on no haurien de ser. En el millor del casos queden dins de l'entorn educatiu, però em de preocuparnos de tot lo que ha sortit.

Pensem maleficament ara:

• Alumnes i la metadata dels documents identifiquen als alumnes.
• Professors manegen fitxers amb noms d'alumnes e inclus números d'identificació personals.
• Persones dels dos àmbits (alumne@s i prof@s) amb SDD (Síndrome-de-Diógenes-Digital): fan backup de tot, en medis suposadament segurs, que abans o després deixen de ser-ho.
• Alumnes i professors d'àmbits remots, tornen als seus jocs d'origen: inclús abans d'acabar el curs e inclus amb qualificacions aceptables, si més no sense gaire justificació.

Després no ens ha de sobtar que:

• Gran part dels attacks ransomware, es produeixin en períodes vacacionals.
• La nostra informació sigui en fitxers per fishing.
• Ens facin trucades estranyes e insistents de serveis de qualsevol mena, que no en volem pero que tractem d' evitar donant un munt d'informació del nostre entorn o domicili.
• Hi ha inclus qui contesta enquestes telefòniques, avui día.
• ???
• …

¿Que podem fer com a tècnics, desenvolupadors, prof@s, etc?

• Invertir sempre que es fan canvis en vetllar per la seguretar. Proactivament.
• Validar amb ajuts de persones alienes els canvis. La seguretat es una responsabilitat compartida.
• Tenir un backlog on siguin documentats els incidents de seguretat detectats i sobretot els canvis que fixen el problema.
• Cal Actuar discretament, però amb prioritat màxima per tapar el forat de seguretat detectat.
• Si el forat és massa gran, escalar el problema ràpidament.
• Si els nostres iguals, no consideren sigui prioritari i urgent, hem d'escalar la petició d'ajut per varis canals per tal de forçar una actuació higiénica.
• ???
• …

---

Part tècnica

Objectiu

Securitzar els paràmetres, paraules de pas i altres secrets per tal que Docker y Docker-Swarm siguin una eines segures de baix a alt nivell.

Riscos

La part atacant coneixent paràmetres pot intentar a posteri l'atack de injecció de SQL, desbordament de buffer, creació de procesos de captació de dades i malversació en general del sistema Docker.

La part atacant coneixent paraules de pas, pot entrar en la part d'administració del servei, crear backdoors, sabotejar el sistema per conseguir denegació del servei, establir un sistema home-al-mig, entre d'altres.

A continuació s'explica el concepte de secret en detall i com comunicar i crear el pont entre Docker i Docker-Swarm per tal de poder intercanviar secrets mitjançant la comanda «docker swarm join-token».

¿Què són els Secrets?

Pel que fa als serveis de Docker Swarm, un secret és una gota de dades, com ara una contrasenya, una clau privada SSH, un certificat SSL o una altra dada que no s'hauria de transmetre a través d'una xarxa o emmagatzemar sense xifrar en un fitxer Dockerfile o a l'aplicació de la vostra aplicació. codi font. Podeu utilitzar els secrets de Docker per gestionar de manera centralitzada aquestes dades i transmetre-les de manera segura només als contenidors que hi necessiten accedir. Els secrets es xifren durant el trànsit i en repòs en un eixam Docker. Un secret determinat només és accessible per als serveis als quals se'n ha concedit un accés explícit, i només mentre s'executen aquestes tasques de servei.

Podeu utilitzar secrets per gestionar les dades sensibles que necessiti un contenidor en temps d'execució, però no voleu emmagatzemar-les a la imatge o al control de fonts, com ara:

Noms d'usuari i contrasenyes Certificats i claus TLS Claus SSH Altres dades importants com el nom d'una base de dades o servidor intern Cadenas genèriques o contingut binari (fins a 500 kb de mida)

Nota: els secrets de Docker només estan disponibles per als serveis d'eixam, no per als contenidors autònoms. Per utilitzar aquesta funció, penseu a adaptar el vostre contenidor perquè funcioni com a servei. Els contenidors amb estat normalment es poden executar amb una escala d'1 sense canviar el codi del contenidor.

Un altre cas d'ús per utilitzar secrets és proporcionar una capa d'abstracció entre el contenidor i un conjunt de credencials. Penseu en un escenari en què tingueu entorns de desenvolupament, proves i producció separats per a la vostra aplicació. Cadascun d'aquests entorns pot tenir credencials diferents, emmagatzemades als eixams de desenvolupament, proves i producció amb el mateix nom secret. Els vostres contenidors només necessiten saber el nom del secret per funcionar en els tres entorns.

També podeu utilitzar secrets per gestionar dades no sensibles, com ara fitxers de configuració. Tanmateix, Docker admet l'ús de configuracions per emmagatzemar dades no sensibles. Les configuracions es munten directament al sistema de fitxers del contenidor, sense utilitzar un disc RAM.

Ordre en línia

Aquesta ordre funciona amb l'orquestrador Swarm.

$docker swarm join-token [OPCIONS] (worker|manager)

Descripció

Els tokens d'unió són secrets que permeten a un node unir-se al swarm. Hi ha dos tipus de tokens d'unió diferents disponibles:

• Un per al rol de treballador (worker).
• Un altre per al rol de gestor (manager).

En executar swarm join, el token es traspasa fent servir el paràmetre «–token». Els nodes utilitzen el token només quan s'uneixen al swarm.

Important!

Aquesta es una comanda de gestió del cluster i s'ha d'executar en el gestor de nodes swarm.

[OPCIONS]

–quiet només mostra el token. -q mateix efecte que –quiet. –rotate Rotació del token d'unió.

–rotate:

Com que els tokens permeten que nous nodes s'uneixin al swarm, hauríeu de mantenir-los en secret. Aneu especialment amb compte amb els tokens de gestor, ja que permeten que nous nodes de gestor s'uneixin al swarm.

Un administrador malició té el potencial d'interrompre el funcionament del vostre swarm.

Gireu el token d'unió del vostre swarm si surten canvis inesperats al control de versions, si és robat o un node està compromès. També és possible que vulgueu girar el testimoni periòdicament per assegurar-vos que les filtracions de testimoni desconegudes no permetin que un node maliciós s'uneixi al swarm.

(worker|manager)

Worker o Mánager sobre el que executem l'ordre.

Exemples

https://docs.docker.com/engine/reference/commandline/swarm_join-token/#examples

---

Referències Externes

General sobre Docker: https://docs.docker.com/engine/swarm/secrets/

Docker swarm: https://docs.docker.com/engine/reference/commandline/swarm/Enllaç extern

Docker swarm join-token: https://docs.docker.com/engine/reference/commandline/swarm_join-token/