Voorkom “configuration drift” in de cloud, gebruik deployment stacks

Stel je voor: “Ik heb het in het portaal aangepast, kun je het even verwerken in Azure DevOps?” Als platform engineer ben je waarschijnlijk bekend met het uitrollen van resources in de cloud. En zoals het hoort, maken wij gebruik van infrastructure as code, via Azure DevOps of Github. Maar wat als dit niet gebeurt? Dan kan configuratiedrift ontstaan. Als je configuratiedrift niet onmiddellijk aanpakt, kan dit later voor problemen zorgen. Laten we dus eens kijken naar een handige manier om configuratiedrift te voorkomen: deployment stacks.

Wat zijn deployment stacks?

Deployment stacks zijn een extra laag over je deployment heen waarmee je de status van je resources kunt monitoren. Hierdoor worden wijzigingen alleen toegestaan als het via de deployment stack zijn doorgevoerd. Het dwingt je eigenlijk om alles netjes via de deployment stack te doen.

Deny assignment

Binnen je stack geef je aan welke beveiliging je aan je resources wil meegeven. Je hebt keuzes, zoals:

• None: Resources kunnen verwijderd en aangepast worden.
• Deny Delete: Resources kunnen wel aangepast worden, maar niet verwijderd worden.
• Deny Write And Delete: Resources kunnen zowel niet gewijzigd als verwijderd worden.

Updaten van je stack

Als je resources uit de stack verwijdert, kun je kiezen wat er met deze resources moet gebeuren. De standaardinstelling laat de resources binnen Azure staan, maar onbeheerd. Je kunt ze dan zelf uitschakelen of verwijderen. Maar je kunt ook kiezen om de resources en resourcegroepen helemaal te verwijderen. Vooral voor grotere bedrijven is dit handig, omdat het verwijderen van resources vaak een handmatig proces is waar verhoogde rechten voor nodig zijn.

Waarom exclusions?

Exclusions geven je de mogelijkheid om bepaalde resources of service principals een uitzondering te geven om resources aan te passen of te verwijderen. Dit is handig in gevallen waarin:

1. Resources andere resources willen aanpassen, bijvoorbeeld een recovery vault die oude back-ups wil verwijderen.
2. Policies een service principal gebruiken om wijzigingen aan te brengen aan een resource.

Nadeel
In grotere omgevingen gebeuren dagelijks veel deployments. Stel je voor dat je veel Azure Policy assignments hebt; deze moeten allemaal rechten krijgen binnen de deployment stacks om aanpassingen te mogen doen. Op dit moment kun je slechts vijf identiteiten toevoegen aan een deployment stack die rechten krijgen om resources aan te passen. Dus de kans is groot dat we meer gebruik moeten gaan maken van user assigned identity bij Azure Policy om ervoor te zorgen dat deze binnen de 5 identiteiten vallen.

Conclusie

Deployment stacks zorgen ervoor dat je resources niet zomaar aangepast of verwijderd kunnen worden. Ze ruimen ook netjes alle resources op wanneer je ze niet meer nodig hebt. Het enige is dat je wat meer moet nadenken over hoe je je Azure Policies wilt inrichten. Dus waar wacht je nog op? Bel ons voor een adviesgesprek en ontdek wat nog meer mogelijk is!