“The Ansible”, volgens de interwebs is dit begrip, door de Ansible Founder Micheal de Haan, geleend van Ender’s Game. Etymologisch is de oorsprong van het woord in 1966 door schrijfster Ursula Le Guin bedacht. In de geest van Ursula wordt in Ender’s Game een apparaat omschreven als de “Philotic Parallax Instantaneous Communicator” en deze geeft de mogelijkheid om over afstand van lichtjaren realtime te communiceren met, in dit geval, een vloot ruimteschepen.
Ansible vat ik zelf graag samen als een idempotent, agentless, automation framework die met tekst based YAML “syntax” in structuur van “playbooks”, “modules”, “roles” en “collections” devices kan aansturen. Zie ook : https://www.ansible.com/overview/how-ansible-works.
De Community Edition is voorzien van allerhande modules en collections, de Core Edition van Ansible kun je zelf aankleden met collections die wenselijk zijn. Om gebruik te maken van Ansible is gemiddelde kennis van Linux, Python en wat affiniteit met programmeren aan te raden.
Nu verklaring, mogelijke lading en verwachting van het begrip “Ansible” duidelijker is wil ik uitweiden hoe wij Ansible toepassen in networking, security en compliancy.
Binnen het SolidBE klantenbestand monitoren en beheren wij duizenden devices en poorten. Met behulp van monitoring proxy’s op klantlocaties centraliseren we, de door de proxy’s verkregen data, naar onze NOC en SOC dashboards, waar onze support medewerkers acteren op gegenereerde meldingen en problemen.
Ansible stelt ons o.a. in staat om de monitoring proxy’s (veelal Linux VM’s op de compute laag van de klant zelf) en de benodigde configuratie op de infrastructuur devices te combineren. Voor een klant die wij “in beheer” nemen zorgen we eerst voor een inventarisatie van alle devices. Gegevens en credentials worden aangemaakt en/of overgedragen, ingevoerd en versleuteld opgeslagen in onze CMDB.
Met behulp van ETL’s genereren we uit onze CMDB “inventory” en/of “vars” files voor gebruik met Ansible. Deze Ansible bronnen, met sensitieve gegevens, worden vervolgens weer versleuteld met behulp van ansible-vault. Ansible-vault maakt decryptie tijdens het draaien van een ansible playbooks mogelijk zodat die gegevens nooit inzichtelijk zijn. Voor de lezer bekend met Ansible, inderdaad, “no_log” is your friend om dergelijke gegevens tijdens executie te onderdrukken.
Door het grote aanbod van Ansible, is het mogelijk om voor praktisch alle vendors een “collection” te vinden die aansluit voor het aansturen van hun producten. Waar het een onbekende vendor betreft of verouderde devices zijn, biedt de standaard “network_cli” uitkomst. Daarnaast hebben enkele grote vendoren zelf git repo’s met hun modules en collections, die gemakkelijk zijn te downloaden en modulair zijn te installeren.
Nadat er een inventory van devices gemaakt is en een playbook met de bijpassende parameters voor de benodigde collection is aangemaakt kan Ansible, voor bijvoorbeeld Cisco apparatuur, in bulk snmp of log host settings doorvoeren op de switches. De combinatie met de monitoring proxy systemen is dat dezelfde inventory kan worden gebruikt om bv. NAT tabellen te genereren of de syslog daemon toe te spitsen voor een bepaalde klant of verzameling van devices.
Om bij te houden wie, wat, waar en wanneer welke wijziging gedaan is, het “audit trail”, staat de Ansible omgeving in een git repository. Op elke wijziging wordt door middel van een git pull request het 4-eyes principe toegepast voordat deze in de master repo komt die op productie wordt toegepast.
Ook voor onze FWaaS dienst benutten we op deze wijze het toevoegen en wijzigen van policies met behulp van Ansible en git op het FortiGate platform. Hier geldt hetzelfde 4-eyes principe dat toegepast wordt voordat deze in de master repo op productie wordt toegepast.
Voor onze hosting activiteiten en interne automatisering combineren we met Ansible de rol van een server, bijvoorbeeld een webserver, met de benodigde firewall policies. De playbook, voorzien van de benodigde variabelen, configureert dan enerzijds bv. de config files en certificaten van een apache webserver en anderzijds de benodigde firewall policies voor die webserver op een FortiGate.
Binnen onze R&D omgeving, aka “het lab”, is Ansible onderhand onmisbaar in deployment en provisioning van baseline omgevingen die we daarna verder uitbouwen voor de benodigde tests.
Voor one-off changes is gebruik van Ansible ook zeer effectief. Gezien we networking devices ook backuppen met behulp van Ansible hebben we voor alle (beheerde) klanten een inventory. Wanneer we dan infrastructuur beheren, maar SIEM is bijvoorbeeld onder beheer van een andere partij en de SIEM beheerders wijzigen iets in hun omgeving dan is het zaak aan SolidBE om bijvoorbeeld de logging hosts te wijzigen of een ACL aan te scherpen.
Het is in zo’n situatie gemakkelijker om eenmalig de benodigde commando’s uit een collectie uit te zoeken, op te nemen in een playbook en los te laten op de devices in plaats van op elk device afzonderlijk inloggen en de configuratie doorvoeren. Eenmaal gemaakt kunnen deze playbooks later weer hergebruikt worden en daarnaast dienen ze als audit trail van doorgevoerde wijzigingen in een omgeving, want ook een one-off playbook gaat gewoon de git repo in. Een ander zeer praktisch voorbeeld van one-off en zelfs one-liner gebruik van Ansible tegen networking devices is “even snel” een lijst met versies, firmware of modules opvragen van devices.
Conclusie is dat Ansible en gebruik daarvan de afgelopen jaren enorme ontwikkeling heeft doorgemaakt buiten en binnen SolidBE. Het zorgt dat we meer in minder doorlooptijd kunnen doen op een veilige, gecontroleerde en compliance ready methode.
