HTTPS (DevOpsin tapaan) palomuurin takana toimiville verkkosovelluksille

Ongelma

Verkkosovelluksissa SSL/HTTPS-yhteys on välttämätön. Yksinkertaisesti sanottuna salaamaton HTTP-liikenne on tietoturvariski.

Tämä ei ole uutta, ja on vaikea löytää tuotannossa olevaa julkista verkkopalvelua, jota ei olisi suojattu SSL:llä. Ei-tuotantoympäristöissä tilanne on kuitenkin täysin toinen.

DevOps-konsulttina olen menettänyt laskuista, kuinka usein olen nähnyt ei-tuotanto-, kehitys-, testi-, QA- ja staging-ympäristöjä, joissa käytetään tavallista HTTP:tä. Yleisesti ottaen tärkeimmät syyt ovat mielestäni seuraavat:

• Nämä ympäristöt ovat usein palomuurin takana eivätkä ne ole ulkomaailman käytettävissä. Siksi kehittäjät eivät välttämättä koe tarvitsevansa sertifikaattia, koska intranetissä tai lähiverkossa tuntuu turvalliselta.

• Sertifikaatin hankkiminen ja uusiminen vie usein aikaa, kun Let’s Encryptiä ei voida käyttää.

• Prosessi on usein manuaalinen tai keskitetty toiseen organisaatioon, mikä ei sovi CI/CD-ohjattuihin kehitysprosesseihin.

Kysy keneltä tahansa tietoturva-asiantuntijalta, niin hän kertoo, että tällaisia verkkoja murretaan jatkuvasti ja salaamaton liikenne on haavoittuvaa. Turvallisuuden tunne on väärä.

CI/CD:tä käyttävät kehitystiimit työskentelevät nopeasti – julkaisuja tehdään tiheästi sekä vanhoihin että uusiin toimituksiin, joten sertifikaatin luomista ei voida jäädä odottamaan. Uusi palvelu otetaan käyttöön sisäisissä ympäristöissä, mutta ilman SSL/HTTPS:ää.

CI/CD:ssä käyttöönotto on automatisoitu, eikä ole mahdollista, että automatisoidut käyttöönotot ja testit rikkoutuvat sertifikaatin uusimista odotettaessa.

Ratkaisu

Paras tapa varmistaa, että mikä tahansa verkkopalvelu toimii HTTPS:n yli voimassa olevalla sertifikaatilla, on tehdä siitä mahdollisimman vaivatonta – automaation avulla. Kun otat verkkopalvelun käyttöön, tämän pitäisi tapahtua automaattisesti. DevOps-lähestymistapa on automatisoitu ja toistettava.

Let’s Encrypt mahdollisti tämän julkisille verkkopalveluille käyttämällä Automated Certificate Management Environment (ACME) -protokollaa.

Tästä ei kuitenkaan ole suurta apua ei-julkisissa ei-tuotantoympäristöissä. Jos haluat käyttää Let’s Encryptiä, palomuuriin on avattava yhteys jossain kohtaa. Yleinen esimerkki voisi näyttää seuraavalta kaaviolta:

Tämä edellyttää, että:

• Käytät DNS-01-haastetta.

• DNS-palveluntarjoajasi tukee ACME-protokollaa.

• Verkkotunnus on julkaistu, vaikka se ei olisikaan saavutettavissa.

• Käytössäsi on mekanismi sertifikaattien jakeluun. 

• Palomuurissa on aukko jossain kohtaa.

Tämä ratkaisu ei ole optimaalinen monesta ilmeisestä syystä.

Onneksemme Smallstep tarjoaa varmentajan (CA), joka tukee ACME-protokollaa. Se on avoimen lähdekoodin kevyt ratkaisu, joka tarjoaa useita tapoja sertifikaattien käyttöönottoon ja hallintaan. 

Smallstep CA on rakennettu DevOpsia ja moderneja järjestelmiä varten. Sen voi paketoida konttiin, ajaa K8's-klusterissa ja automatisoida Chef-, Ansible-, Puppet- ja muiden käyttöönotto- ja hallintatyökalujen avulla. Näin saat Let’s Encryptin kaltaisen kokemuksen ja sertifikaattien automatisoidun hallinnan.

Tämän ratkaisun kaavio näyttäisi suunnilleen tältä:

• HTTP-01-haaste on yksinkertaisempi. 

• DNS-palveluntarjoajaa ei tarvitse ottaa mukaan.

• Palomuuria ei tarvitse avata.

• Verkkotunnuksia ei tarvitse julkaista. 

• Sertifikaattien jakelua varten ei tarvitse toteuttaa ja ylläpitää omaa mekanismia, sillä käytettävissä on monia ACME-asiakkaita. Mainittakoon muutama: Traefik, ACME.sh, Certbot ja Smallstepin CLI.

• Monet organisaatiot käyttävät ja jakavat jo sisäisesti allekirjoitettuja sertifikaatteja. Smallstep CA:n avulla voit tuoda juurisertifikaatit.

Tämä on huomattavasti selkeämpi ratkaisu. 

Demo

Olen luonut repositorion, jossa on yksinkertainen demototeutus Smallstepin CA:sta palomuurin takana toimivalla ratkaisulla. 

Dockeroin CA:n ja loin docker-compose-tiedoston, jonka avulla sen saa helposti käyntiin. Entrypoint-skripti alustaa CA:n .env-tiedostossa määritetyillä arvoilla.

Seuraavaksi dockeroin kaksi proxya, Nginxin ja Traefikin, ja loin niille docker-compose-tiedostot. Niillä voi havainnollistaa sertifikaattien luontia ja uusimista yksinkertaiselle ”Hello World!” -verkkopalvelulle.

Valitsin Traefikin, koska siinä on sisäänrakennettu tuki ACME:lle. Määritä compose-tiedostoon oikeat arvot (CA, haastetyyppi jne.), niin Traefik hoitaa kaiken, myös sertifikaattien uusimisen.

Valitsin Nginxin, koska siinä ei ole sisäänrakennettua tukea ACME:lle. Sen sijaan sisällytin Smallstepin CLI:n, joka tukee sertifikaattien luontia ja uusimista, Nginx-imageen ja loin entrypoint-skriptin sertifikaatin luomista sekä uusintadaemonin käynnistämistä varten. Nginxin konfiguraatio viittaa vain sertifikaatteihin, jotka Smallstepin ACME-asiakas luo ja uusii.

Kokeile kloonaamalla repositorio ja seuraamalla Quick Start -opasta. Perusprosessi on kuitenkin seuraava:

1. Täytä .env-tiedostoon tarvittavat ympäristömuuttujat.

2. Päivitä hosts-tiedostosi.

3. Käynnistä CA-kontti, hae fingerprint ja lisää se .env-tiedostoon.

4. Lisää CA:n kontin käynnistyessä luoma juurisertifikaatti isäntäkoneesi luottamusvarastoon. Normaalisti ITOPs hoitaisi tämän.

5. Käynnistä Traefik tai Nginx nähdäksesi sertifikaatin luonnin.

Tässä on asennuksen esittelevä ruutukaappausvideo. Siinä näytetään sertifikaattiviranomaisen käynnistäminen, luotujen juuri- ja välisertifikaattien lisääminen isäntäkoneen luottamusvarastoon sekä Traefikin ja Nginxin käynnistäminen yksinkertaisen ”Hello World!” -verkkopalvelun proxyiksi.

Huomioitavaa:

• Kun CA-kontti käynnistetään, se alustetaan entrypointissa ja juuri- sekä välisertifikaatit luodaan.

• Smallstepin CA tukee useita provisioner-tyyppejä, joista oletustyyppi on JWK. Entrypoint lisää kuitenkin ACME-provisioner-tyypin, koska haluamme käyttää sitä.

• Sekä Traefik- että Nginx-imaget sisältävät Smallstepin CLI:n valmiiksi sisällytettynä. CA välittää liikennettä HTTPS:n kautta. Siksi asiakaskonttien luottamusvarastoon on lisättävä juuri- ja välisertifikaatit. CLI:tä käytetään tähän kontin entrypointissa.

• Käytän Smallstepin CLI:tä paikallisesti lisätäkseni sertifikaatit tietokoneeni luottamusvarastoon. Se pakkaa ne puolestani .pem-tiedostoon, joten minun ei tarvitse tehdä sitä käsin.

• Kontit käyttävät konfigurointiin ympäristömuuttujia. Tämä ei oikeastaan 

turvallinen, ja kaikkeen muuhun kuin demoon tulisi käyttää tiedostopohjaista lähestymistapaa.

Yhteenveto

Demo osoittaa, että SSL-varmenteiden käsittely voidaan automatisoida, kun Let’s Encryptiä ei voida käyttää palomuurirajoitusten vuoksi. 

Käytännössä operatiivisen tiimin tulisi omistaa ja hallinnoida varmentajaa (CA). He ovat joka tapauksessa vastuussa juuri- ja välivarmenteiden jakamisesta verkon tarvittaville isännille. 

Tässä blogissa ei käsitellä myöskään itse CA:n hallintaa, vaan keskitytään siihen, miten sitä käytetään Let’s Encrypt -kokemuksen tarjoamiseksi kehitystiimeille. 

Kannustan operatiivisia tiimejä keskustelemaan Smallstepin asiantuntijoiden kanssa siitä, mitä muuta CA:lla voidaan tehdä, sekä perehtymään CA:n hallinnan yksityiskohtiin. Tällaisen ratkaisun tarjoaminen tukee vahvasti DevOps-ajattelutapaa, jossa kehityksen ja operoinnin välisiä raja-aitoja puretaan; uskaltaisinko jopa sanoa, että se tukee myös DevSecOpsia? 

Hyödyt kehityksen, operoinnin ja tietoturvan näkökulmasta ovat melko ilmeiset:

• Verkkopalvelujen liikenne on oletusarvoisesti salattua. Tietoturva hymyilee :-)

• Automatisoitu SSL-varmenteiden hallinta poistaa manuaaliset varmenteiden käsittelyprosessit. Operointi hymyilee :-)

• Vakaammat ympäristöt, jotka vastaavat tuotantoa paremmin ja pysyvät kehityksen vauhdissa. Kehitys hymyilee :-)