HTTPS (på DevOps-vis) för webbapplikationer bakom brandväggen

Problemet

För webbapplikationer är kommunikation över SSL/HTTPS ett måste. Enkelt uttryckt innebär okrypterad HTTP-trafik en säkerhetsrisk.

Det här är inget nytt, och det är svårt att hitta en publik webbtjänst i produktion som inte är säkrad med SSL. I icke-produktionsmiljöer ser det däremot helt annorlunda ut.

Som DevOps-konsult har jag tappat räkningen på hur många gånger jag har sett icke-produktions-, utvecklings-, test-, QA- och stagingmiljöer som kör vanlig HTTP. Generellt sett tror jag att de främsta anledningarna är:

• Dessa miljöer finns ofta bakom en brandvägg och är inte exponerade mot omvärlden. Därför känner utvecklare sällan behov av att skaffa ett certifikat, eftersom de upplever sig som trygga på ett intranät/LAN.

• Processen för att skaffa och förnya ett certifikat är ofta tidskrävande när Let’s Encrypt inte kan användas.

• Processen är ofta manuell eller centraliserad till en annan organisation, vilket inte passar utvecklingsprocesser som drivs av CI/CD.

Fråga vilken säkerhetsexpert som helst, så kommer de att säga att sådana nätverk komprometteras hela tiden och att okrypterad trafik är sårbar. Känslan av trygghet är falsk.

Utvecklingsteam som arbetar med CI/CD har högt tempo – releasecyklerna är täta för både gamla och nya leveranser, och att vänta på att ett certifikat skapas är inte ett alternativ. Den nya tjänsten kommer att driftsättas i de interna miljöerna, men inte med SSL/HTTPS.

I CI/CD är driftsättningsprocessen automatiserad, och det är inte ett alternativ att automatiserade driftsättningar och tester slutar fungera medan man väntar på att ett certifikat ska förnyas.

Lösningen

Det bästa sättet att säkerställa att en webbtjänst körs över HTTPS med ett giltigt certifikat är att göra det så smidigt som möjligt – genom automatisering. När du driftsätter en webbtjänst ska det bara fungera. Och ett DevOps-arbetssätt är automatiserat och repeterbart.

Let’s Encrypt gjorde detta möjligt för publika webbtjänster med protokollet Automated Certificate Management Environment (ACME).

Men det hjälper inte särskilt mycket för icke-publika icke-produktionsmiljöer. För att använda Let’s Encrypt behöver du öppna brandväggen någonstans. Ett vanligt exempel kan se ut som i följande diagram:

Detta kräver att du:

• Använder DNS-01-utmaningen.

• Har en DNS-leverantör som stöder ACME-protokollet.

• Har publicerat domänen, även om den inte är åtkomlig.

• Har en mekanism för att distribuera certifikaten.

• Har en öppning i brandväggen någonstans.

Den här lösningen är av flera uppenbara skäl inte optimal.

Som tur är erbjuder Smallstep en certifikatutfärdare (CA) som stöder ACME-protokollet. Den är open source, lättviktig och erbjuder flera sätt att etablera och hantera certifikat.

Smallstep CA är byggd för DevOps och moderna system. Den kan paketeras i en container, köras i ett K8's-kluster och automatiseras med verktyg för provisionering som Chef, Ansible, Puppet och andra. Det gör det möjligt att få samma upplevelse som med Let’s Encrypt och automatiserad hantering av certifikat.

Ett diagram över den här lösningen skulle kunna se ut ungefär så här:

• HTTP-01-utmaningen är enklare.

• Du behöver inte involvera en DNS-leverantör.

• Du behöver inte öppna brandväggen.

• Du behöver inte publicera domäner.

• Du behöver inte implementera och underhålla en mekanism för att distribuera certifikaten, eftersom det finns många befintliga ACME-klienter som kan användas. Några exempel är Traefik, ACME.sh, Certbot och Smallsteps CLI.

• Många organisationer använder och distribuerar redan internt signerade certifikat. Med Smallstep CA kan du importera rotcertifikaten.

Det här är en betydligt renare lösning.

Demonstrationen

Jag har skapat ett repository med en enkel demo-implementation som använder Smallstep CA med lösningen bakom brandväggen.

Jag dockeriserade CA:n och skapade en docker-compose-fil för att enkelt starta den. Det finns ett entrypoint-skript som initierar CA:n med värden som definieras i en .env-fil.

Jag dockeriserade sedan och skapade docker-compose-filer för två proxyservrar (Nginx och Traefik) för att visa hur du får certifikatgenerering och förnyelse för en enkel webbtjänst med ”Hello World!”.

Jag valde Traefik eftersom det har inbyggt stöd för ACME. Du behöver bara konfigurera compose-filen med rätt värden (CA, challenge-typ osv.), så hanterar Traefik allt, inklusive certifikatförnyelse.

Jag valde Nginx eftersom det inte har inbyggt stöd för ACME. I stället inkluderade jag Smallsteps CLI, som stöder certifikatgenerering och förnyelse, i Nginx-imagen och skapade ett entrypoint-skript som genererar certifikatet och kör förnyelsedaemonen. Nginx-konfigurationen refererar bara till de certifikat som Smallsteps ACME-klient genererar och förnyar.

För att prova själv klonar du repositoryt och följer guiden Quick Start. Grundprocessen ser dock ut så här:

1. Fyll i några miljövariabler i .env-filen.

2. Uppdatera din hosts-fil.

3. Starta CA-containern, hämta fingeravtrycket och lägg till det i filen .env.

4. Lägg till rotcertifikatet som CA:n genererar när containern startas i din värddators trust store. Normalt skulle detta hanteras av ITOPs.

5. Starta Traefik eller Nginx för att se certifikatgenereringen.

Här är en skärminspelning som visar konfigurationen. Den visar hur certifikatutfärdaren startas, hur de genererade rot- och mellanliggande certifikaten läggs till i värddatorns trust store och hur Traefik och Nginx startas för att agera proxy för en enkel webbtjänst med ”Hello World!”.

Det finns några saker att notera:

• När CA-containern startas initieras den i entrypoint-skriptet, och rot- och mellanliggande certifikat genereras.

• Smallstep CA stöder flera typer av provisioners, där standardtypen är JWK. Men entrypoint-skriptet lägger till en ACME-provisioner, eftersom det är den vi vill använda.

• Både Traefik- och Nginx-imagen har Smallsteps CLI inbyggt. CA:n hanterar trafik över HTTPS. Därför behöver klientcontainrarna ha rot- och mellanliggande certifikat tillagda i containerns trust store. CLI:t används för att göra detta i containerns entrypoint-skript.

• Jag använder Smallsteps CLI lokalt för att lägga till certifikaten i min dators trust store. Den paketerar dem i en .pem-fil åt mig, så jag behöver inte göra det manuellt.

• Containrarna använder miljövariabler för konfiguration. Det är egentligen inte

säker, och en filbaserad metod bör användas för allt utöver en demo.

Sammanfattning

Demon visar att det går att automatisera hanteringen av SSL-certifikat när Let’s Encrypt inte kan användas på grund av brandväggsbegränsningar.

I verkligheten bör driftteamet äga och hantera certifikatutfärdaren (CA). De ansvarar ändå för att distribuera rot- och mellanliggande certifikat till de värdar i nätverket som behöver dem.

Den här bloggen behandlar inte heller hanteringen av själva CA:n, utan fokuserar på hur du använder den för att ge utvecklingsteamen samma upplevelse som med Let’s Encrypt.

Jag vill uppmuntra driftteam att prata med teamet på Smallstep om vad mer som kan göras med CA:n och fördjupa sig i detaljerna kring hanteringen av den. Att erbjuda något sådant här stödjer verkligen DevOps-principen att riva barriärerna mellan utveckling och drift; vågar jag säga att det till och med stödjer DevSecOps?

Fördelarna ur ett utvecklings-, drift- och säkerhetsperspektiv är ganska uppenbara:

• Krypterad trafik för webbtjänster direkt från start. Säkerhetsteamet ler :-)

• Automatiserad hantering av SSL-certifikat och färre manuella processer för certifikathantering. Driftteamet ler :-)

• Stabilare miljöer som bättre liknar produktionstakten och möter utvecklingens behov. Utvecklingsteamet ler :-)