HashiCorp lanceert nieuwe versie van Consul multi-cloud service mesh-platform

HashiCorp maakt vandaag bekend dat de bèta­versie van Consul 1.8.0 per direct beschik­baar is. Consul is een multi-cloud service mesh-platform dat het mogelijk maakt om services binnen elk runtime-platform, publieke of private cloud te verbinden en te beveiligen.

Deze release biedt de volgende nieuwe functies:

• Ingress Gateway: deze native Consul-oplossing maakt het mogelijk om appli­ca­ties buiten de service mesh te laten commu­ni­ceren met services binnen de mesh
• Termi­na­ting gateway: stelt appli­ca­ties binnen de service mesh in staat om te commu­ni­ceren met services buiten de mesh
• Bundeling van WAN-verkeer via Mesh Gateways: maakt federatie van Consul-data­cen­ters mogelijk door WAN-gossip en RPC-verkeer door te leiden via mesh-gateways. Op deze manier hoeven Consul servers niet direct aan het WAN te worden blootgesteld
• Audit logging (alleen Consul Enter­prise): legt alle infor­matie die bevei­li­gings­be­heer­ders nodig hebben op inzich­te­lijke wijze vast. Dit maakt het makke­lijker voor hen om bevei­li­ging analyses en risi­co­be­oor­de­lingen uit te voeren
• Single Sign-On (alleen Consul Enter­prise): stelt operators in staat om de iden­ti­teits­ve­ri­fi­catie af te laten handelen door brow­ser­ge­ba­seerde Single Sign-on (SSO)-oplossingen zoals Okta. Gebrui­kers kunnen zo op basis van self­ser­vice ACL-tokens genereren voor het beheer van groepen, diensten, names­paces, Consul KV, centrale confi­gu­ra­ties en meer. Daarmee ontstaat een workflow voor het aanle­veren van tokens voor services en gebrui­kers op basis van iden­ti­teits­ve­ri­fi­catie met SSO.

Ingress Gateway

IT-profes­si­o­nals die een beroep doen op service mesh-tech­no­logie merken vaak dat het onboar­ding- en migra­tie­proces voor appli­ca­ties tijd in beslag neemt en gefaseerd verloopt. Om deze reden commu­ni­ceren appli­ca­ties binnen fysieke of virtuele data­cen­ters met de appli­ca­ties binnen de mesh via een gateway. Deze gateway biedt de moge­lijk­heid van noord-zuid verkeer naar de upstream service (oftewel de service die uitein­de­lijk op het verzoek reageert).De Ingress Gateway is een component van Consul dat operators een snelle en eenvou­dige manier biedt om services over te zetten naar de service mesh van Consul.

HashiCorp heeft in deze release ‘Ingress Gateway’ toege­voegd als nieuwe optie voor de opdracht consul connect envoy. Daarmee wordt een Envoy-instance uitge­voerd die is gecon­fi­gu­reerd om een dyna­mi­sche subset van Connect-services open te stellen voor systemen en gebrui­kers buiten de mesh. Dit maakt het mogelijk om toegang tot services te verlenen via de Envoy-proxy (die intern gebruik­maakt van mutual TLS) zonder de noodzaak van authen­ti­catie of inte­gratie met de service mesh van Consul. De ingress gateway kan optioneel worden gecon­fi­gu­reerd om een door Consul gege­ne­reerd TLS-certi­fi­caat te presen­teren voor de versleu­te­ling van netwerkverkeer. 

Hierdoor kunnen externe services onder­han­delen over een betrouw­bare TLS-verbin­ding met de ingress gateway als ze de Consul Certi­fi­cate Authority vertrouwen.

Terminating gateway

Consul service mesh biedt versleu­telde commu­ni­catie tussen diensten via mTLS. De onder­linge verbin­dingen tussen services worden beheerd door Connect-inten­tions. Deze bepalen of een service een verbin­ding met een andere service mag maken. Inten­tions vereen­vou­digen de netwerk­be­vei­li­ging, omdat de segmen­tatie is gebaseerd op service-ID’s in plaats van kort­ston­dige bron-IP-adressen en doel-IP-adressen.

De overstap naar service mesh vindt vaak staps­ge­wijs plaats, als gevolg van beperkte personele middelen of een gebrek aan infra­struc­ture auto­ma­tion. In een derge­lijke situatie kunnen gebrui­kers tijdens de over­gangs­fase geruime tijd gebruik maken van services binnen en buiten de service mesh. Er zijn ook scenario’s te bedenken waarin bepaalde services zich nooit binnen de mesh bevinden.

In deze onver­mij­de­lijk hybride omge­vingen moeten services binnen de mesh een recht­streekse verbin­ding maken met externe services. Dit doet afbreuk aan de gebruik­s­er­va­ring als a) verschil­lende services op verschil­lende manieren worden gede­tec­teerd, b) niet alle verbin­dingen met mTLS zijn versleu­teld en c) Connect-inten­tions slechts een subset van verbin­dingen beheren. Deze beperking van Connect-inten­tions doet afbreuk aan een van de belang­rijkste voordelen van Connect. Firewall-teams zullen nog altijd moeten zorgen voor veilige verbin­dingen van kort­ston­dige service-adressen binnen de mesh naar service-adressen buiten de mesh. De oplossing voor dit probleem zou niet moeten inhouden dat al het verkeer van de meshed omgeving wordt open­ge­steld voor de externe services. Het is van cruciaal belang om voor een beperking te zorgen van het aantal nodes die derge­lijke verbin­dingen tot stand kunnen brengen.

In deze release werd het concept van een termi­na­ting gateway aan de service mesh van Consul toege­voegd. Termi­na­ting gateways zijn uitgaande proxy’s die mTLS-verbin­dingen van Connect termi­neren, intenties toepassen en verzoeken door­leiden naar de doel services.

WAN-federatie via mesh gateways

IT-infra­struc­turen bevinden zich om verschil­lende redenen maar zelden binnen een co-located omgeving met optimale connec­ti­vi­teit en lage latency. Consul biedt de moge­lijk­heid om elk onderdeel van de co-located IT-omgeving te verenigen tot één Consul-data­center (LAN join). Deze afzon­der­lijke data­cen­ters kunnen vervol­gens worden gefe­de­reerd tot een Consul Cluster (WAN join). De onder­linge commu­ni­catie tussen de services van deze data­cen­ters wordt afge­han­deld door mesh-gateways aan de netwerk rand. Om commu­ni­catie tussen de Consul-servers in elk data­center mogelijk te maken, moeten de servers direct weder­zijds bereik­baar zijn via hun door het WAN aange­kon­digde netwerk­adres. Dit resul­teert in een complexe omgeving en maakt de Consul-servers vatbaar voor beveiligingsproblemen. 

Met deze release maakt HashiCorp het mogelijk om data­cen­ters te federeren op een manier waarbij alleen de mesh-gateways aan het WAN worden bloot­ge­steld. Dit draagt bij aan krach­tiger bevei­li­ging en verbe­terde gebruik­s­er­va­ring tijdens het inrichten van de omgeving.

Audit Logging (alleen Consul Enterprise)

Omdat Consul een zakelijke software oplossing is, moeten veel gebrui­kers voldoen aan wet- en regel­ge­ving zoals HIPAA, PCI en de GDPR. Dit vraagt om een gede­tail­leerd overzicht van alles wat er zich binnen het systeem plaatsvindt.

In deze release voegt HashiCorp Audit Logging toe aan Consul. Deze functie biedt:

Een inzich­te­lijk en praktisch toepas­baar logbe­stand van geve­ri­fi­eerde gebeur­te­nissen. Dat geldt zowel voor pogingen als daad­wer­ke­lijk uitge­voerde hande­lingen binnen het systeem. Op die manier kan worden vast­ge­legd welke bewer­kingen mensen in Consul uitvoeren. Om tegemoet te komen aan de eis van ondub­bel­zin­nige over­een­stem­ming met de wet- en regel­ge­ving tijdens het gebruik van Consul hebben operators en bevei­li­gings­me­de­wer­kers een historie nodig van alle gebeur­te­nissen die direct door mensen in gang zijn gezet. Alle gebeur­te­nissen zijn voorzien van een tijd­stempel, een beschrij­ving van de uitge­voerde bewerking en de gebruiker die deze in gang heeft gezet. Func­ti­o­na­li­teit die standaard veilig is. Het is belang­rijk dat gebrui­kers niet van auditing afzien omdat dit ten nadele gaat van de pres­ta­ties van Consul. Gebrui­kers die de meeste behoefte hebben aan auditing zijn naar alle waar­schijn­lijk­heid ook de gebrui­kers die Consul op zijn prestatie limieten wil laten draaien. HashiCorp wil operators realis­ti­sche verwach­tingen bieden ten aanzien van hun audit logs, zodat ze Consul op elke gewenste schaal kunnen inzetten en auditen.

Single Sign-On (alleen Consul Enterprise)

Gebrui­kers die toegang tot Consul willen krijgen, laten hun iden­ti­teit tradi­ti­o­neel alleen met behulp van ACL-tokens veri­fi­ëren. Dit zijn toegangs-ID’s die alleen binnen Consul bestaan. Veel orga­ni­sa­ties willen Consul echter inte­greren met hun bestaande authenticatiesystemen.

Single Sign-On biedt operators de moge­lijk­heid om de iden­ti­teits­ve­ri­fi­catie over te laten aan brow­ser­ge­ba­seerde SSO-oplos­singen zoals die van Okta, zodat gebrui­kers op basis van self­ser­vice, ACL-tokens kunnen verkrijgen voor het beheer van groepen, services, names­paces, Consul KV, centrale confi­gu­ra­ties en meer. Daarmee ontstaat een workflow voor de aanle­ve­ring van tokens voor services en gebrui­kers op basis van hun SSO-identiteit.