Waarom is Identity Brokering voor machines belangrijk? 

Kerim Satirli, senior Developer Advocate HashiCorp

Als het gaat om Secrets Management is een van de meest gestelde vragen:
Wat is het verschil tussen HashiCorp Vault en een keystore zoals AWS Secrets Manager of Azure Key Vault, en een cloud-onafhankelijke optie voor statisch Secrets Management?

Over het algemeen maken Statische keystores veilige opslag van secrets mogelijk en staan API-gebaseerde retrieval toe. Alle grote Cloud Service Providers (CSP) bieden hun eigen vorm van key storage. Daarnaast zijn er verschillende cloudneutrale oplossingen op de markt. In het geval van CSP key vaults, is authenticatie meestal gebaseerd op een identiteit die door de cloud wordt geleverd, zoals een Machine Identity in Azure of IAM in AWS.

Cloudneutrale key stores daarentegen maken voor het authenticatieproces vaak gebruik van een vooraf gedefinieerde reeks van aanmeldingsgegevens of verificatievragen, waaronder IP-bindings (vaste adressen). De manier waarop zij toegangsmachtigingen aan gebruikers toewijzen heeft een sterk transactioneel karakter.

Koppelen van identiteiten

Hoewel Vault zeker de mogelijkheid heeft om als secrets manager te fungeren en één op één relaties te managen, is de belangrijkste onderscheidende factor ervan dat het identiteiten kan koppelen. Het voordeel van zo’n identity broker is dat een eigen identiteit kan worden gebruikt in diverse omgevingen, zowel on premise als in meerdere clouds, zonder afhankelijk te zijn van een specifieke IP of authenticatie via verificatievragen.

Door gebruik te maken van identity brokering beschikken we over meer flexibiliteit, veilige authenticatie op alle niveaus van onze applicatiestack en betere observability tussen systemen. Omdat brokering een many-to-many relatie mogelijk maakt, wordt de operationele complexiteit verminderd, wat resulteert in toegevoegde waarde doordat er meer aandacht is voor declaratieve, relationele authenticatie en autorisatie.

Identity Brokering en machine-identiteiten

Het meest bekende gebruik van identity brokerage is Single Sign On (SSO). Door gebruik te maken van SSO kan een gebruiker zich authenticeren bij één systeem, dat vervolgens die identiteit verspreidt over meerdere systemen en ervoor zorgt dat de eindgebruiker de juiste authenticatie en autorisatie krijgt. Vergelijk het met een persoon die een financiële adviseur benadert om informatie te krijgen over meerdere producten.

Vaak vergeten we dat brokering ook nodig is voor machine-identiteiten, net zoals we SSO gebruiken voor personen. Maar naarmate microservices steeds vaker de architectuur bepalen, wordt het ook gebruikelijker dat applicaties toegang nodig hebben tot meerdere bronnen.

Een applicatie die bijvoorbeeld toegang nodig heeft tot een database, SSH en DataDog, kan gebruik maken van een identity broker om ervoor te zorgen dat deze resources door één enkel authenticatiemechanisme kunnen worden beheerd. In het geval van gedeelde assets wordt een centrale oplossing belangrijker voor de observability en controle van geauthenticeerde resources.

Is Identity Brokerage ook van belang wanneer er met één cloud gewerkt wordt? 

De overstap naar de cloud is ingewikkeld en resulteert realistisch gezien zelden in één enkele cloudstrategie; dit kan het gevolg zijn van strategiewijziging, regelgeving, problemen met de migratie van legacy-infrastructuur of bijvoorbeeld zelfs een bedrijfsovername.

Bovendien worden er steeds meer microservice-architecturen gebruikt, met als gevolg gedeelde resources. Credentials die worden gedeeld via e-mail of messaging diensten komen vaker voor dan wenselijk is. Het vergroot niet alleen de kans op een potentieel credential lek, maar ook een reëel risico op ongewenste verspreiding van deze credentials.

In dat laatste ongewenste geval zijn credentials niet alleen onbeheerd en ongecontroleerd, maar creëren ze ook risico wat betreft de applicatie beschikbaarheid, vooral naarmate er complexere architecturen zijn waarbij de kans op gedeelde services groter is.

Wanneer bijvoorbeeld een developer het wachtwoord voor de database-referenties van applicatie A wisselt, zonder applicatie B hiervan op de hoogte te stellen, kan applicatie B daardoor uitvallen. Maar als machtigingen voor de database gemanaged worden op basis van identity brokerage, kan het database wachtwoord rouleren zonder enige zorg voor verslechtering van beschikbaarheid en service.

Momenteel gebruikt 50% van de organisaties een vorm van Kubernetes, waarbij de bedrijven die andere vormen van containerisatie gebruiken, zoals Rancher of Nomad, niet zijn meegerekend. Ondanks het feit dat Kubernetes “cloud native” is, brengt het gebruik van CSP-managed Kubernetes zijn eigen uitdagingen met zich mee op het gebied van identiteitsbeheer.

In AWS is het mogelijk om clusters te beheren met AWS IAM, maar zoals bij alle grote cloudproviders blijft de identiteit op clusterniveau, waardoor identiteitsbeheer op pod-level vrijwel onmogelijk is zonder het gebruik van een CSI-driver of een tool van derden. In Azure is Machine Identity niet beschikbaar voor AKS, met als eindresultaat dat cluster identity management gebonden is aan een gebruikersidentiteit, wat verre van ideaal is als onweerlegbaarheid een zorg is.

In het geval van Google Cloud en GKE, als er gebruik wordt gemaakt van workload-identiteit bij het starten van een nieuwe pod, kan het voorkomen dat de metadata nog niet beschikbaar is en de operatie niet slaagt. Het eindresultaat is een inconsistent beheer van workloads.

Als we SSO gebruiken voor personen, waarom dan niet voor machines? 

SSO voor gebruikers is al bijna drie decennia lang van belang om de kloof tussen menselijke identiteit en authenticatie te dichten. We zouden kunnen speculeren over waarom federatie van applicatie-identiteit niet prominenter is geworden. Maar hoe dan ook, de huidige staat van applicatie-identiteit laat ons achter met een gefragmenteerde, gedecentraliseerde, zeer handmatige aanpak.

Hoewel de meeste cloud providers native identiteiten hebben voor hun resources, is het verenigen daarvan in een enkele, controleerbare, gecontroleerde workflow zonder een gecentraliseerde brokerage complex, niet menselijk leesbaar, en niet schaalbaar vanwege de complexiteit die nodig is voor automatisering. Door gebruik te maken van een brokerage mechanisme kunnen we een uniforme workflow garanderen over alle vereiste applicatielagen, van netwerk tot applicatie over meerdere resources.

Auteur: Kerim Satirli, senior Developer Advocate HashiCorp

Lees ook:

Gerelateerde berichten...