‫Ik gebruik Docker-geheimen voor mijn wachtwoorden, maar dit
‫maakt gewoon een RAM-bestand in de container.
‫Als iemand de container heeft gehackt, kunnen ze
‫het bestand zien, net als mijn applicatie.
‫Ja en nee.
‫Geweldig. We blijven praten. Is er een
‫betere manier om dit te doen? De inhoud van het geheim versleutelen?
‫Decodeer vervolgens in de applicatie op een manier die een hacker
‫niet zou kunnen achterhalen.
‫De realiteit hier
‫is dat je applicatie ergens zijn geheim moet hebben, en
‫ze zullen niet-versleuteld in het geheugen zijn, toch.
‫Alles wat ik weet dat versleutelde dingen ontsleutelt, ontsleutelt
‫het in het geheugen. Als een hacker
‫root in je container heeft, kan
‫hij die dingen krijgen.
‫Als ze slim genoeg zijn, kunnen ze dat
‫spul krijgen, toch.
‫De eerste stap is om uw toepassing niet als root in
‫de container uit te voeren.
‫Dan kunnen ze niet rondscharrelen met iets
‫buiten de applicatie. Ze kunnen geen andere systeemhulpprogramma's
‫in de container uitvoeren die mogelijk al het geheugen kunnen lezen, toch.
‫Het tweede is dat er echt de
‫veiligste manier is die we volgens mij hebben gezien, zoiets als
‫een kluis en eenmalige wachtwoorden waar ze worden gemaakt, ze
‫worden gebruikt door je app, en dan worden ze
‫weggegooid en niet langer Goed. De realiteit is dat de meeste mensen
‫daar niet klaar voor zijn. De apps van de meeste mensen kunnen dat niet aan.
‫Weet je, je kunt niet elke vijf minuten een Twitter API-sleutel draaien
‫voor elke app die wordt gestart, toch.
‫Dit soort dingen. Het beste is
‫om te voorkomen dat dat bestand ooit permanent op
‫schijf staat.
‫Een Kubernetes-beveiliging
‫en Docker-beveiliging, die... sorry geheimen, Kubernetes geheimen en zwerm
‫geheimen zijn enkele van de beste manieren die ik ooit
‫heb gezien om een manier te bedenken om
‫wachtwoorden op te slaan in een
‫nepbestand in RAM. Je kunt die machtigingen zo instellen dat
‫ze alleen door je app kunnen worden gelezen, toch.
‫Dus als iemand op de een of andere manier met een andere gebruiker
‫binnenkomt, niet dat je per se een
‫andere gebruiker in de container zou hebben, maar je kunt diegene vergrendelen zodat ze alleen-lezen
‫zijn, dat ze alleen door de gebruiker kunnen worden gelezen dat
‫is jouw app. Dat is het soort dingen, toch.
‫Dus dat is het echt.
‫Het enige dat ik beter heb gezien, slaat ze nog steeds op
‫in het geheugen, nog steeds onversleuteld.
‫Het slaat ze alleen niet lokaal op.
‫U moet dus een externe API gebruiken
‫zoals Vault, HashiCorp's Vault of een ander systeem dat
‫eenmalige wachtwoorden levert. Maar nogmaals, die dingen zouden over je
‫hele systeem moeten worden gebouwd. Je zou het hele ding
‫moeten ontwerpen. En dat is een hoop werk, toch.
‫Terwijl je, met behulp van de geheimen in Kubernetes
‫en Swarm, die dingen meestal op dezelfde dag gedaan
‫kunt krijgen, toch. Je kunt dat voor
‫zowat elke app implementeren, zelfs als het ze als omgevingsvariabelen moet
‫instellen, omdat oudere applicaties dingen in omgevingsvariabelen vereisen.
‫Je kunt ze dus in het geheim hebben en dan,
‫tijdens runtime, die geheimen laten dumpen in omgevingsvariabelen
‫als dat nodig is. Maar ik zou zeggen
‫99% van de tijd, mijn adviserende klanten, hebben te maken met legacy-applicaties.
‫Als ik legacy zeg, bedoel ik echt alles vóór
‫containers, en dat zijn de meeste applicaties, toch.
‫We hebben 30 jaar gewerkt aan het maken van applicaties
‫zonder containers voordat we ze hadden.
‫We hebben dus veel vaste dingen.
‫Dus de meeste teams zijn gewoon aan het kijken hoe ze dingen in
‫containers kunnen krijgen en ze versleuteld op schijf kunnen opslaan, toch.
‫Als ze op schijf staan, zijn ze versleuteld.
‫Kubernetes en Swarm kunnen dat allebei.
‫Ik denk dat als je geheimen gebruikt, je al beter
‫bent dan 99% van de mensen die ik zie, omdat maar
‫heel weinig mensen orkestratie gebruiken en ook geheimen.
‫Het is een heel, heel kleine groep, een stel mensen.
‫Dus ja, ik denk dat je daar best goed zit.