Legacy Chronicles - AWS Systems Manager

Julkipilven kiistatta parhaita puolia on niiden käyttöönoton helppous ja nopeus. Projektiorganisaatiot voivat ketterästi validoida uusia liikeideoita, ja kehittäjät saavat nopeasti pystyyn uusia ympäristöjä. Pilviarkkitehdin työn veikeimpiä puolia ovat puolestaan tilanteet, joissa tällaiset ketterät kokeilut ovat päätyneet kokeilumoodissa tuotantoon ja unohtuneet mahdollisesti pitkäksikin aikaa.

Viime syksynä asiakas pudotti syliimme kasan AWS:ssä pyöriviä EC2-palvelimia saatesanoilla "tässä olis tällaisia ja jotain pitäis tehdä, ottakaa haltuun". Tällaisessa tilanteessa pitää saada akuutisti tehtyä seuraavat asiat:

1. Palvelinten tietoturva ajan tasalle

2. Selvyys siitä mitä palvelimilla pyörii ja ovatko ne tarpeellisia

3. Varmuuskopiot kuntoon

4. Logit talteen

Yleensä kannattaa myös harkita onko palvelimia mielekästä pyöritellä sellaisenaan, vai onko järjestelmä niin tärkeä että sama toiminnallisuus kannattaa toteuttaa kokonaan uudelleen. Usein suosimme vähintään kevyttä refaktorointia tai kokonaan uuden pilvinatiivin infrastruktuurin rakentamista. Tässäkin tapauksessa päädyimme sopivaan refaktorointiin ja päädyimme tekohengittämään palvelimet sekä määrittelemään asiakkaalle joustavan, konttipohjaisen alustan jolla jatkossa pyörittää näitä ja muita vastaavia järjestelmiä. Keskityn tässä kirjoituksessa tekohengittämiseen, jonka osalta oleellisia ovat listan kohdat 1 ja 2. (Kolmosen ja nelosen saa meiltä palveluna)

Saimme asiakkaalta pääsyn AWS-tilille ja palvelimille, joten ei muuta kun lapio käteen ja hommiin. Ensimmäinen havainto oli, että palvelimilla ajettiin Ubuntun versiota 14.04, joka on tämän kirjoitushetkellä elinkaarensa loppupäässä. Käyttöjärjestelmät pitäisi siis saada päivitettyä ennemmin kuin myöhemmin. Palvelimilla pyöri lähinnä erinäisiä WordPress- ja MySQL-asennuksia, joten kohdan 2 osalta keikassa ei ollut mitään erityisen ihmeellistä.

AWS julkaisi taannoin Systems Managerin, joka sopii tällaisiin tilanteisiin kuin nakutettu. Sen avulla palvelinten ja muiden resurssien tilanteeseen saa helposti näkyvyyden, ja sitä voi käyttää resurssien keskitettyyn hallintaan. Päätimme hyödyntää Systems Manageria tietoturvapäivitysten tekemiseen keskitetysti. Mukavana bonuksena sillä saisi hallittua myös kehittäjien pääsyt palvelimille IAM-tunnuksilla, jolloin niistä jää automaattisesti audit trail eikä palvelimille tarvitse tehdä erillisiä virityksiä käyttäjätunnuksia varten. Teoriassa Systems Managerin käyttöönotto on helppoa: asenna agentti palvelimelle ja valmista tuli. Lisäksi palvelimille tarvitaan IAM-rooli joka mahdollistaa palvelinten kommunikoinnin SSM-rajapinnan kanssa.

Ansible siis käteen ja agentit kaikille pannuille pyörimään. Ensimmäinen ongelma: kaikkia palvelimia ei näkynyt SSM:n inventaariossa lainkaan, ja osa näkyi connection lost -tilassa, vaikka agentin asennus näytti pinnallisin puolin onnistuneen. Tarkistimme että palvelimilla on oikea IAM-rooli eikä missään ole palomuuria estämässä liikennettä. AWS:n päässä security groupit näyttivät oikeilta, eikä pannuilta löytynyt iptables-virityksiä. Teimme samaan aliverkkoon samoilla asetuksilla testiksi uuden Ubuntu 14.04 -palvelimen, jonka kanssa SSM toimi kuten pitääkin. Tässä vaiheessa huomasimme, että toimimattomat palvelimet on itseasiassa pystytetty jostakin kustomoidusta imagesta - testipalvelimemme sen sijaan oli Amazonin tarjoama AMI. Periaatteessa palvelimilla saattoi siis olla ihan mitä tahansa leipomuksia.

Hommassa oli potentiaalia kehittyä todella kummalliseksi, joten tässä vaiheessa kysyimme näkemystä myös AWS:n tuelta. Mitään haittaakaan kysymisestä ei ole, ja usein AWS:ltä saa arvokasta näkemystä tällaisissa hieman eksoottisimmissa tapauksissa. Omassa päässämme otimme puolestaan SSM-agentin logit käteen. Logeissa pisti silmään, että palvelimen instanssi-id oli mi-alkuinen, kun yleensä EC2:n id:t alkavat i-kirjaimella.

"Setting up websocket for controlchannel for instance: mi-06745f6170fb0fe84, requestId: 2d068de2-c906-4133-9753-46c9d790efee"

Logimerkintä herätti epäilyksen palvelinten alkuperästä. Tällaisen mi-alkuisen instanssi-id:n saavat nimittäin SSM:llä hallinnoidut on-premise -palvelimet. Asiakas tiesi kertoa, että palvelimet oli alunperin lift 'n shiftattu heidän VMWare-ympäristöstään AWS:ään. SSM julkaistiin loppuvuonna 2017, ja mysteeripalvelimemme oli pystytetty alkuvuonna 2018 jostakin custom imagesta. Ilmeisesti alkuperäisessä migraatiossa VMWare-palvelimista oli luotu sellaisenaan AMI, josta oli pystytetty nämä uudetkin palvelimet. Tämän imagen mukana on sitten kulkeutunut uusien palvelinten levynkulmalle tämä SSM-rekisteröinti.

AWS-tuen kaveri kertoi törmänneensä joskus ongelmiin tällaisten hybridiympäristöjen kanssa, ja ohjeisti poistamaan SSM-agentin hakemistosta kaiken vanhaan instanssi-id:hen viittaavan.

$ ls -al /var/lib/amazon/ssm/

drw------- 7 root root 4096 Oct 26 2017 .

drw------- 3 root root 4096 Oct 26 2017 ..

drw------- 3 root root 4096 Oct 26 2017 Vault

drw------- 2 root root 4096 Oct 26 2017 daemons

drw------- 5 root root 4096 Oct 26 2017 i-07fbc8dfc7a9207f5

drw------- 3 root root 4096 Oct 26 2017 localcommands

drw------- 7 root root 4096 Oct 15 10:24 mi-06745f6170fb0fe84

-rw------- 1 root root 68 Oct 26 2017 registration

Poistimme mi-06745f6170fb0fe84 -hakemiston sekä registration-tiedoston, jonka sisältö hienovaraisesti vihjasi että palvelin tosiaan haluaa rekisteröidä itsensä väärällä instanssi-id:llä.

{"ManagedInstanceID":"mi-06745f6170fb0fe84","Region":"eu-central-1"}

Käynnistimme SSM-agentin uudelleen, mutta palvelin ei vieläkään näkynyt SSM:n inventaariossa. mi-06745f7170fb0fe84 -hakemistokin oli putkahtanut jostain takaisin, mutta mistä? Väärä id ei pyörinyt missään konfiguraatioissa tai palvelimen metadatassa. Yritimme poistaa palvelinta myös SSM:n päästä, mutta kyseisellä id:llä sitä ei löytynyt.

$ aws ssm deregister-managed-instance --instance-id "mi-06745f6170fb0fe84"

"An error occurred (InvalidInstanceId) when calling the DeregisterManagedInstance operation:"

Tässä vaiheessa poistimme koko SSM-agentin ja asensimme sen uudelleen. Tällaisenaan toimenpide ei auttanut, sillä agentin itsensä poistaminen ei poista sen välimuistia. Näin ollen vanha rekisteröinti putkahtaa jälleen esille kun agentin asentaa uudelleen. Homma saatiin lopulta pelittämään paremmin poistamalla agentti, tyhjentämällä koko /var/lib/amazon/ssm/ -hakemisto ja tämän jälkeen asentamalla agentti uudelleen. Näiden temppujen jälkeen kaikki palvelimet yhtä lukuunottamatta näkyivät Systems Managerissa online-tilassa kuten pitääkin.

Tämän yhden palvelimen osalta mysteeri ei oikeastaan ikinä selvinnyt. AWS-tuki halusi palvelimen SSM-agentin debug-logit, jotka saa enabloitua tunkkaamalla SSM:n käyttämän Seelogin konfiguraatio-XML:ää. Linux-ympäristössä tiedosto asustaa polussa /etc/amazon/ssm/seelog.xml, ja debug-logit saa enabloitua vaihtamalla seelog-elementin minlevel-attribuutin arvosta "info" arvoon "debug". Tuki mainitsi myös, että connection lost -tilassa olevat palvelimet poistuvat SSM:stä 30 päivän kuluessa elleivät ne sitä ennen saa SSM:n yhteyttä. Laskeskelimme, että tätä painiottelua oli käyty sen verran kauan että palvelin kokisi luonnollisen poistuman noin viikon kuluttua joka tapauksessa, joten kovin intensiivinen tunkkailu ei maksaisi vaivaa. Jätimme SSM-agentin pyörimään palvelimelle ja jäimme odottelemaan, että AWS-tuki kävisi debug-logit läpi tai että 30 päivän määräaika tulisi täyteen. Kuinka ollakaan, eräänä päivänä töihin tullessani totesin että palvelin oli ilmestynyt online-tilaan ja AWS-tuki vahvisti että tämä johtui 30 päivän määräajan täyttymisestä.

Tietoturvapäivitykset ovat pyörineet palvelimilla automaattisesti nyt joitakin kuukausia, ja kehittäjät ovat käytelleet SSM:ää oikein tyytyväisinä silloin kun ovat tarvinneet pääsyä palvelimille. Palvelu toimii siis erittäin hyvin, mutta täysin ongelmatonta sen käyttöönotto ei ollut. Tyypillisessä tapauksessa homma lienee helpompaa etenkin kun SSM-agentti tulee tätä nykyä AWS:n ylläpitämien AMI:en mukana (ja normaalitilanteessa kannattaa käyttää näitä imageja ilman mitään omia virityksiä). Toisaalta tämä oli oikein mielenkiintoinen oppitunti SSM:n sielunelämästä ja siitä mitä yllätyksiä saattaa tulla kun palvelimia lift 'n shiftataan konesalista tai muusta virtuaaliympäristöstä julkiseen pilveen. Tällaisten yllätysten takia emme Cloud2:lla ole niitä lift 'n shiftin suurimpia faneja, mutta se on jo sitten ihan toinen tarina...