Verbeter de beveiliging van je applicaties op AWS, deel III

Automatisering, Ansible, AWS

In onze vorige posts over Verbeter de beveiliging van je applicaties op AWS, (deel I en deel II) hebben we uitgelegd dat service platforms zoals AWS, Microsoft Azure en Google Cloud Platfrom zo slim zijn als hun gebruikers, immers de vereiste architectuur dient gebouwd te worden door mensen die verstand hebben van gebieden als beveiliging, netwerken etc. Tevens hebben we gezien dat ondanks de gebruikersvriendelijkheid van de AWS console, we vele manuele stappen moeten doorlopen om de gewenste architectuur te definieren. Vanwege het ontbreken van een grafische representatie van de overall architectuur is het eenvoudig om het spoor bijster te raken als we de architectuur niet vooraf plannen of hiervan een draft optekenen.

Vanwege het feit dat een architectuur wordt opgebouwd middels services die gedefinieerd worden in verschillende tabllen met onderlinge relaties en vele manuele stappen vereist zijn is het opbouwen van een dergelijke architectuur tijdrovend en voorziet het niet in de flexibiliteit die we wensen voor onze systemen om onze business scenarios te kunnen dienen. Gelukkig beschikt AWS over een API die ons de mogelijkheid biedt om onze architecturen op AWS te automatiseren, middels tools als Ansible, Chef, Puppet etc. kunnen we gebruik maken van de AWS API.

In dze blog kijken we naar Ansible en tonen we hoe we de architectuur die we in onze vorige blogs over Vebeter de beveiliging van je applicaties op AWS hebben beschreven kunnen automatiseren.

Wat is Ansible?

Ansible is een krachtige IT automatiserings engine die je in staat stelt om applicaties sneller op te leveren. Aangezien elk onderneming tegenwoordig een digitale onderneming is en technologie de motor van innovatie is om je applicaties/oplossingen sneller uit te vaardigen helpt het organisaties om concurrerend te blijven en te win door tijd te reduceren die gespendeerd wordt aan repeterende taken.

Ansible stelt je in staat om repeterende taken te voorkomen middels het automatiseren hiervan, dit zorgt ervoor dat administrators worden ontlast en zich kunnen focussen op de inspanningen die helpen bij het leveren, en het bouwen aan een cultuur van succes. Ultiem levert het iets waarvan we nooit genoeg hebben, nl. tijd. Hierdoor zijn slimme mensen in staat om zich te concentreren op slimme zaken. Ansible is een simpele automatiseringstaal die perfect een IT applicatie infrastructuur kan beschrijven. Het is eenvoudig aan te leren, zelf documenterend en het vereist geen hoog nivo kennis van computer wetenschap.

Ansible ondersteund een breed bereik van verschillende modules die kunnen worden geautomatiseerd: Cloud Modules, Clustering Modules, Command Modules, Crypto Modules, Database Modules, File Modules, Identity Modules, Inventory Modules, Messaging Modules, Network Modules, Packaging Modules, Remote Management Modules, Source Control Modules, Storage Modules, Utilities Modules, Web Infrastructure Modules, Windows Modules.

 

Wij zullen gebruik maken van de Cloud Module Amazon EC2 om onze repeterende taken te automatiseren die we voorheen via de AWS console moesten definieren, dit geeft ons meer controle en flexibiliteit. Ansible ondersteund een lange lijst van methoden die voor EC2 kunnen worden gebruikt, zie hieronder een overzicht. (Wij zullen gebruik maken van enkele van deze methoden in ons voorbeeld, deze zijn rood onderstreept.)

 

 

Playbooks

Playbooks zijn Ansible's configuratie, deployment en orchestratie taal voor remote machines, in ons geval een multi-machien deployment op AWS. Playbooks kunnen onder source code beheer zoals Git etc. worden gehouden. Playbooks worden uitgedrukt middels het YAML formata en hebben een minimale syntax, die opzettelijk probeerd geen programmeertaal of script te zijn, maar liever een model van configuratie of een proces.

Elke playbook bestaat uit een lijst van een of meerdere 'plays'. Het doel van een play is om een groep hosts te plannen middels goed gedefinieerde rollen, gerepresenteerd middels Ansible taken. Op basisniveau is een taak niets meer dan een oproep naar een Ansible module zoals de hierboven beschreven AWS modules.

Door het opbouwen van een Playbook met meerde 'plays' is het mogelijk om multi-machine implementaties te orchistreren.

Je kunt meer details vinden over Playbooks, Handlers, Tasks, Roles en Variables in de documentatie van Ansible welke kan worden gevonden middels de volgende url: http://docs.ansible.com/ansible/latest/playbooks.html

 

Voorbeeld Architectuur

Onze voorbeeld architectuur bestaat uit een VPC, een Private en Public subnet, een Internet Gateway, een NAT Gateway, een Bastion Server, Route tables en Security Groups. Het voorbeeld is niet bedoeld voor een productie omgeving maar meer als een introductie hoe je repeterende taken op AWS kunt automatiseren middels Ansible, je kunt dit voorbeeld aanpassen naar je eigen benodigdheden.

Allereerst hebben we een diskstructuur aangemaakt voor onze Playbook, zie hiertoe de afbeelding hieronder.

Ansible kan ingezet worden tegen meerdere systemen in je infrastructuur op hetzelfde moment, dit wordt mogelijk gemaakt door het selecteren van verschillende delen van de systemen die opgesomt zijn in het inventory bestand. In dit bestand kun je Hosts, Groups, Host Variables, Group Variables etc. specficeren. In ons voorbeeld bevat het inventory bestand de sectie local zoals te zien uit de onderstaande afbeelding, dit betekend dat de Ansible playbook vanaf onze lokale machine wordt gestart.

Vervolgens hebben we de globale variabelen gedefinieerd zie in onze Playbook kunnen worden gebruikt in het vars.yml bestand zoals getoond in onderstaande afbeelding.

Zoals we kunnen zien hebben we de AWS credential (access_key and secret_key) als globale variabelen gedefinieerd omdat we onszelf dienen te autoriseren bij AWS als we een API methode via de Ansible Cloud Module voor Amazon willen aanroepen. Tevens kunne we zien dat we een aws_region hebben gespecificeerd waarbinnen we willen werken als ook de ip-adressen voor de VPC, Public en Private Subnet evenals de te gebruiken AMI voor de Bastion Server. Verder hebben we ons eigen ip-adres my_ip gespecificeerd waarmee we naar de AWS instances willen connecteren. Also we can see that we specified an aws_region in which we like to work as well as the ip addresses of the VPC, Public and Private Subnet as well as the AMI to be used for the Bastion Server. Aan deze variabelen kunnen we refereren in de taken, in plaats van deze hierin hard-coded op te nemen.

 

In het playbook.yml bestand hebben we onderstaande gespecificeerd, de betekenis hiervan is dat de rol vpc op de lokale machine wordt uitgevoerd. (De taken voor de vpc rol zijn gedefinieerd in de subdirectory /roles/vpc/tasks)

In de tasks subfolder vinden we het main.yml bestand welke de taken bevat die door Ansible worden uitgevoerd. We hebben met opzet enkele van deze variabelen grijs gemaakt zodat je zelf kunt proberen deze architectuur te complementeren daar die voor oefining en beter begrip zorgt in plaats van het voorbeeld over te kopieren.

Uit het voorbeeld kunnen we zien dat de volgende stappen worden uitgevoerd:

  • allereerst het aanmaken van de VPC (gebruikmakend van de globale variabelen zoals gedefinieerd in het vars.yml bestand)
  • vervolgens het verkrijgen van de VPC facts en de VPC route table facts, omdat we de default route die door Amazon wordt aangemaakt bij het aanmaken van een VPC willen wijzigen
  • vervolgens maken we het Public en Private subnet aan
  • vervolgens maken we de Internet Gateway aan
  • vervolgens maken we een Elastic IP aan welke gebruikt wordt voor de NAT Gateway in de volgende stap
  • vervolgens maken we een NAT Gateway aan
  • vervolgens modificeren we de Public Subnet Route table
  • vervolgens maken we de Private Subnet Route table aan
  • vervolgens maken we de Private en Public Subnet Security Group aan
  • en als laatste maken we de Bastion Server aan

Nu dat we klaar zijn met het Ansible script om de de architectuur uit te vaardigen op AWS, kunnen we het uitvoeren middels het volgende commando:

ansible-playbook playbook.yml -i inventory -e @vars.yml vanuit de Ansible Playbook directory vpctest, we hebben hiervoor een shell script deploy.sh aangemaakt die we als volgt kunnen uitvoeren: ./deploy.sh

Als we dit script uitvoeren zien we de status van de Ansible taken over ons scherm scrollen, hieronder zie je een afbeelding van de laastste stappen van het script.

In de AWS console kunnen we nu het resultaat bekijken van ons script, het dient er ongeveer zoals hieronder uit te zien.

Virtual Private Network:

Public en Private subnet:

Public en Private Route Tables:

Internet Gateway:

NAT Gateway:

Public en Private Security Group:

Bastion Server:

 

Vervolgens kunnen we ons Ansible script maken om deze architectuur af te breken, je kunt dit zelf proberen.

Conclusie

Middels Ansible en de AWS API kunnen we repeterende taken op AWS automatiseren, dit maakt templating mogelijk en geeft veel meer flexibiliteit dan de AWS console voor het opbouwen, starten en het afbreken van een architectuur.

Het enige wat ook Ansible ontbeerd is een grafisch overzicht van de taken die worden uitgevoerd middels een Playbook. Als je graag wilt werken met grafische bouwstenen en gebruik wilt maken een drag en drop interface kun je wellicht eens kijken naar VisualOps http://www.visualops.io, VisualOps maakt eveneens gebruik van de AWS API en is in staat om je VPC architectuur uit AWS in te lezen, waarna je deze kunt wijzigen en opnieuw kunt deployen. Eveneens kun je je VPC architectuur via drag en drop vanaf nul opbouwen en op AWS deployen en tevens ben je in staat om deze met een druk op de knop te vernietigen.

Toen wij VisualOps gebruikten kwamen wij erachter dat niet alle recente services van AWS worden ondersteund, bijvoorbeeld de NAT Gateway. Verder levert VisualOps veel gebruikersgemak, met name het grafische overzicht van je totaalarchitectuur is prettig.

Daarentegen als je weet hoe Ansible werkt ben je waarschijnlijk op termijn beter af omdat VisualOps alleen voor AWS kan worden ingezet en Ansible een multi-purpose automatiserings tool is die bijvoorbeeld ook gebruikt kan worden voor je eigen Linux en Windows systemen.

We hopen dat je genoten hebt van deze drie delen blog over Verbeter de beveiliging van je applicaties op AWS.

Ronald Span

Founder of Scalar Data, over 20 years of experience in a variety of national and international IT projects in different roles, development, consultancy, pre-sales, management and business development. Scalar Data is helping organizations to implement their big data strategy.