Begin dit jaar gaf onze AWS-lead Bart Tange een kennissessie over self-service met de Service Catalog van AWS in diverse smaakjes. Hierin lichtte hij de voor- en nadelen van deze service toe en wat je er zoal mee zou kunnen doen. Hij sloot de sessie af met een demo waarin het delen tussen verschillende AWS-accounts met verschillende rechten werd gedemonstreerd. In deze 'recap' van Bart zijn sessie licht hij de belangrijkste punten nogmaals uit. Een demo geven gaat natuurlijk lastig in een stuk geschreven tekst, dus voor alle in's en out's kun je het beste een van onze volgende sessies op locatie volgen!
Het probleem...
Stel, je hebt als bedrijf een platform binnen AWS. Je bent goed bezig dus je hebt met je team van architecten en platform engineers een goede indeling gemaakt wat betreft accounts in AWS. Teams met verschillende expertises werken ook in verschillende OU's (Organizational Units) en/of accounts. Wanneer er een aanpassing gewenst is in bijvoorbeeld een account van een developer of security specialist, doen we dit liever niet meteen met een ticket naar het eerdergenoemde platform team. Het zou natuurlijk fantastisch zijn als zij deze change zelf kunnen doorvoeren. Maar deze teams willen niet met Terraform of Cloudformation aan de gang, want dat is hun expertise helemaal niet. Al zouden ze het wel zelf willen bouwen, dan hebben ze hier niet eens de rechten voor! Hoe zorgen we ervoor dat ze dit wel zelf kunnen deployen, zonder daar zelf met code aan de gang te gaan en per ongeluk gevoelige data te lekken of hopeloos achter te gaan lopen met patches door gebrek aan tijd en expertise?
Introducing... de AWS Service Catalog.
Service Catalog
Service Catalog is de service waarmee vanuit een centraal beheerd account een portfolio van producten gedeeld kan worden met andere OU's of accounts. Dit zijn een hoop termen in een zin, dus deze zal ik onderstaand even toelichten.
Product
Een product is effectief gezien een stukje 'Infrastructure as Code' welke door anderen afgenomen kan worden. Deze code wordt beheerd vanuit een centraal account. Aan dit product kunnen verschillende opties meegegeven worden, zodat de gebruiker het naar wens kan instellen.
Stel, we willen de optie aanbieden voor een developer om een S3bucket aan te maken, waarin allerlei best-practices standaard zijn toegepast. Dan zou het er als volgt uitzien:
Portfolio
Vaak bied je niet enkel een los product aan je eindgebruikers, maar een verzameling van producten. Deze verzameling noem je een portfolio.
OU
Organizational Units, een logische groepering waaronder andere OU's of accounts kunnen vallen. Dit kun je zien als een mappenstructuur. Een portfolio wordt meestal per OU gedeeld.
Sharing is caring!
In onderstaande afbeelding is te zien hoe het delen eruit zou kunnen zien. Hier hebben we meerdere OU's, (aangegeven met de rechthoeken) en accounts (aangegeven met de cirkels). In het account met de grote P wordt een portfolio van producten beheerd. Dit portfolio wordt gedeeld met de OU's 'Team 1' en 'Team2'. Je ziet dat de producten beschikbaar worden in de onderliggende accounts door de kleine p's.
Product afnemen
De producten zijn nu beschikbaar in de gewenste accounts. Hoe werkt het afnemen dan precies?
In bovenstaande afbeelding zie je een gebruiker van het product. Laten we in dit geval zeggen een developer die een bucket wilt deployen. Op basis van de rechten die deze developer heeft kan hij verschillende producten zien. In dit geval een database en een bucket. Hij kiest het product bucket en geeft wat parameters mee, zoals bucketnaam en klikt vervolgens op deploy. En zo simpel is het! Er staat nu een bucket, die met alle best practices en bedrijfsstandaarden is ingericht. Volledig serverless, traceerbaar en met least privilege.
Least privilege en IAM policies
Least privilege is het concept waarbij je enkel de rechten hebt die strict noodzakelijk zijn. In dit geval wil de developer een bucket inrichten. Je zou het zo kunnen maken dat je de developer een stuk code geeft om dit te doen en diegene te beperken met IAM policies en te monitoren met AWS Config en Security Hub om te kijken of er geen ongewenste configuraties worden gemaakt. Iedereen die eerder met deze services gewerkt heeft, weet dat dit snel kan oplopen in ontwikkeltijd en kosten. Daarnaast is dit allemaal maatwerk en biedt het kans op fouten met het risico dat bijvoorbeeld een bucket toch publiekelijk beschikbaar blijkt te zijn.
Je voelt het waarschijnlijk al aan, er is een beter alternatief met de Service Catalog. In dat geval geef je de developer helemaal geen rechten om een bucket aan te maken, maar enkel rechten om het product af te nemen. De bucket is al goed ingericht en kan bijvoorbeeld niet opeens per ongeluk publiekelijk beschikbaar zijn! Je geeft de Service Catalog service rechten om de bucket aan te maken. De developer geef je enkel rechten om het product af te nemen.
Cloudformation?! We willen Terraform!
Dit is iets wat je in veel organisaties zult horen als men erachter komt dat een product in principe in Cloudformation aangeleverd dient te worden. Cloudformation is de 'Infrastructure as Code' tool die door AWS wordt gebruikt. Het resultaat van een deployed Cloudformation template is een stack. Een stack is de verzameling services die hoort bij het Cloudformation template en wordt constant in de gaten gehouden of de werkelijkheid nog overeenkomt met de opgegeven configuratie.
Het is een hele mooie tool, maar sommige teams willen nou eenmaal met Terraform werken. Omdat ze hiermee ook zaken buiten AWS inrichten, of omdat dit nou eenmaal wordt afgedwongen in de organisatie. Wat de reden ook mag zijn, het is sinds kort mogelijk met de Service Catalog!
Hier zit (wat mij betreft) wel een hele grote kanttekening bij. Zo zul je hiervoor zelf een flink stuk infrastructuur voor moeten inrichten in je AWS account. Wat je hiervoor precies moet doen staat hier beschreven.
Met de Cloudformation oplossing wordt er bij afname van het product een stack gebouwd in het account van de gebruiker. Met de Terraform Engine gaat dit net even anders. Het bereiken van dit proces omvat het gebruik van een complexe stack met onder andere EC2, Lambda, SQS, S3, Event Bridge en StepFunctions. Dit proces treedt op wanneer een product wordt afgenomen, waarbij er in het centraal beheerde account feitelijk een 'Terraform apply' wordt uitgevoerd. Dit 'Terraform apply' proces maakt de resources aan in het account van de gebruiker. Ook de state wordt in het centrale account beheerd.
Zomaar drie smaakjes
Dat de code voor zo'n product heel eenvoudig kan beginnen en op veel manieren uitgerold kan worden wil ik hier even benadrukken.
Van boven naar beneden: Cloudformation, Terraform en AWS CDK (Python).
Met welke smaak ga jij aan de slag?