Zero Trust Security toepassen op Kubernetes via Service Mesh – The New Stack

Eerder dit jaar vaardigde het Witte Huis een Executive Order on Improving the Nation’s Cyber ​​Security uit, waarmee de basis werd gelegd voor het creëren van een zero-trust-architectuur voor federale agentschappen.

Asher Syed

Ashher is Product Marketing Manager bij HashiCorp, gevestigd in Austin, Texas. Als hij niet achter zijn vier kinderen aan zit, onderzoekt hij de mogelijkheden die cloudgebaseerde technologieën kunnen bieden om bedrijven te moderniseren.

De National Security Agency (NSA) en de Cybersecurity and Infrastructure Security Agency hebben ook gezamenlijk een Kubernetes-hardeninggids gepubliceerd waarin de beste werkwijzen voor de belangrijkste Zero Trust-beveiligingsprincipes in Kubernetes worden belicht.

Deze documenten benadrukken de noodzaak voor organisaties en ontwikkelaars om de manier waarop ze hun applicaties en infrastructuur beveiligen te heroverwegen. Aangezien beveiligingsvereisten veranderen met de adoptie van cloudinfrastructuur, is het absoluut noodzakelijk om te begrijpen hoe u deze principes kunt toepassen op uw runtimes, clouds, platforms en vooral Kubernetes-clusters.

Een belangrijke benadering die door de NSA-richtlijnen wordt aanbevolen, is het gebruik van een servicemesh in Kubernetes-omgevingen om communicatie tussen services te autoriseren, verifiëren en versleutelen. Laten we eens nader bekijken hoe een open source-servicemesh kan helpen uw beveiligingshouding te versterken en zero trust-netwerken te bevorderen.

Beveiliging zonder vertrouwen

Voordat we ingaan op hoe een Zero Trust-aanpak van toepassing is op Kubernetes, hebben we wat context nodig over Zero Trust-principes en waarom ze steeds belangrijker worden.

Het beveiligen van infrastructuur, data en toegang over meerdere clouds en on-premises datacenters wordt steeds complexer en moeilijker. Naarmate organisaties migreren naar multicloud- en hybride infrastructuren, zullen de maatregelen die ze hebben genomen om hun privédatacenters te beveiligen, achterhaald raken. Op IP gebaseerde identiteit en perimetergebaseerde toegang zijn niet langer relevant in een wereld van kortstondige IP-adressen en een steeds veranderend – en vaak extern – personeelsbestand dat constante toegang tot gedeelde bronnen vereist.

Deze verschuiving vereist een andere benadering van beveiliging, een die niets vertrouwt – zelfs niet je eigen diensten en gebruikers – maar in plaats daarvan alles verifieert en autoriseert voordat toegang wordt verleend. Cruciaal is dat de overgang naar Zero Trust niet binair is; Het is een continue aanpak die een fundamentele verandering in uw architectuur vereist. Gelukkig kunnen deze drie best-practice zero trust-principes helpen:

  1. Het verstrekken van op identiteit gebaseerde service-to-service toegang en communicatie: Services moeten gebaseerd zijn op de service-identiteit. De service-identiteit en niet het IP-adres moet worden gebruikt voor autorisatie. En services moeten elkaars identiteit verifiëren bij het maken van verbindingen.
  2. Inclusief geheim- en certificaatbeheer en geharde Kubernetes-codering: Geheimen moeten versleuteld en tijdgebonden zijn en moeten kunnen werken met een wereldwijde service-identiteit die gegevensversleuteling tijdens het transport mogelijk maakt. Referenties moeten tijdgebonden zijn, waardoor de gebruiker of toepassing hun referenties met gespecificeerde intervallen moet bijwerken.
  3. Waarneembaarheid inschakelen met controle en logboekregistratie: Alle toegangspogingen moeten worden gecontroleerd en geregistreerd.

Zero Trust-principes toepassen op Kubernetes

Nu we hebben vastgesteld dat beveiliging op basis van netwerkperimeters niet voldoende is in dynamische omgevingen, moeten we minder vertrouwen op netwerkperimetercontroles. Welke stappen kunnen organisaties nemen om Zero Trust-principes in Kubernetes-omgevingen te implementeren?

1. Het bieden van op identiteit gebaseerde service-to-service-toegang en communicatie

Elk Kubernetes-cluster biedt een plat netwerk waar elke container of service vrij met elkaar kan communiceren. Kubernetes vertrouwt het containernetwerk of de applicaties die erop draaien en vereist geen verificatie. Wanneer bijvoorbeeld een databaseservice en een loggingservice op hetzelfde Kubernetes-cluster draaien, hebben ze standaard toegang tot elkaar op netwerkniveau.

Gebruikers kunnen beleid maken in Kubernetes om standaardregels toe te passen om zowel inkomend als uitgaand verkeer naar het cluster te weigeren. Maar zelfs met deze beperkingen hebt u nog steeds service-naar-service-authenticatie en autorisatie nodig om ervoor te zorgen dat services alleen worden geleverd met de middelen die ze nodig hebben.

U kunt dit probleem oplossen door een servicemesh te introduceren waarmee u service-identiteiten kunt toewijzen aan elke service die op het Kubernetes-cluster wordt uitgevoerd. Op basis van de service-identiteit kan de mesh service-identiteiten verifiëren met behulp van mTLS, en servicetoegangsverzoeken kunnen worden geautoriseerd of geblokkeerd met intenties waarmee operators service-naar-service-communicatiemachtigingen kunnen definiëren op servicenaam. Wanneer een servicemesh aanwezig is, heeft de logboekservice alleen toegang tot de databaseservice als beide services hun referenties aan elkaar kunnen verifiëren.

2. Inclusief geheim- en certificaatbeheer en geharde Kubernetes-codering

Het gebruik van Kubernetes-inloggegevens voor het controlevlak, hetzij voor identiteit of voor het beheren van geheimen, vergroot het aanvalsoppervlak, is moeilijk te onderhouden en voldoet niet aan de hierboven genoemde principes. Kubernetes-geheimen hebben verschillende kwetsbaarheden in een Zero Trust-beveiligingsarchitectuur:

  • Standaard zijn geheimen base-64-gecodeerd, niet versleuteld.
  • Omdat geheimen niet verlopen (ze zijn niet tijdgebonden), kunnen ze u in gevaar brengen.
  • Kubernetes kan alleen resources zoals geheimen binnen een clustergrens beheren. Als u groepen clusters hebt, moeten resources die in meerdere clusters worden gebruikt, afzonderlijk worden beheerd.

Een servicenetwerk met een geheimenmakelaar kan deze uitdaging overwinnen. Consul on Kubernetes heeft bijvoorbeeld een integratie met HashiCorp’s Vault – een gecentraliseerde oplossing voor geheimenbeheer die de gaten in Kubernetes-geheimen opvult.

Het doel is ervoor te zorgen dat geheimen in rust worden versleuteld met gecentraliseerde toegangscontrole en auditing. De werkstroom moet zowel afzonderlijke Kubernetes-clusters als federatieve implementaties met meerdere clusters ondersteunen. Bovendien kan autorotatie van certificaten operators helpen de time-to-live (TTL) -waarden van hun TLS-certificaten te verminderen, waardoor hun beveiligingshouding wordt versterkt.

3. Waarneembaarheid inschakelen met auditing en logging

Om de Kubernetes-beveiliging te verbeteren, is het belang rijk om te begrijpen wat er in het cluster gebeurt om te zien welke servicetoegangsverzoeken zijn gedaan. Met auditlogboeken kan het auditteam gebeurtenisgegevens bekijken om te zien welke referenties zijn gebruikt, welke acties hebben plaatsgevonden en welke tijdstempels aan die transacties zijn gekoppeld. Dit geeft beveiligingsteams meer zichtbaarheid en verantwoordelijkheid.

Een servicemesh zet sidecar-proxy’s in die metrische gegevens kunnen verzenden voor elk van de services die in het cluster worden uitgevoerd en houdt de records bij voor alle service-to-service-communicatie en toegangsverzoeken. Idealiter integreert het servicemesh met open source monitoringtools zoals Prometheus en Grafana om de analyse van servicenetwerkpatronen te vergemakkelijken en de veiligheid te vergroten.

Conclusie

Naarmate serviceleveringsomgevingen complexer worden met meerdere Kubernetes-clusters, meerdere runtimes, multicloud- en on-premises implementaties en al hun verschillende onderlinge verbindingen, wordt het naleven van Zero Trust-beveiligingsprincipes een noodzaak.

Een servicemesh zoals HashiCorp Consul kan een integraal onderdeel van dit proces zijn en een beheerlaag bieden die de Zero Trust-principes afdwingt door op identiteit gebaseerde servicenetwerken te bieden die wederzijds alle toegang authenticeren en autoriseren. Consul maakt het gemakkelijk om gedetailleerd beveiligingsbeleid af te dwingen in Kubernetes en in meerdere omgevingen zonder alle beveiligingsparameters in de applicatie zelf te hoeven coderen, wat resulteert in een snelle, eenvoudig te beheren overgang naar een zero-trust beveiligingshouding.

The New Stack is een volledige dochteronderneming van Insight Partners, een investeerder in de volgende bedrijven die in dit artikel worden genoemd: Enable.

Uitgelichte afbeelding via Unsplash

Leave a Comment