Bezpieczeństwo
Dwa i pół roku danych zniknęło przez podmieniony plik stanu
Alexey Grigorev z DataTalks.Club przesiadł się na nowy komputer bez pliku stanu Terraform, więc gdy poprosił Claude Code o skasowanie duplikatów, agent rozpakował stare archiwum, podmienił ten plik i wziął działającą produkcję za swoje zasoby, po czym terraform destroy zabrał bazę RDS z dwuipółrocznym dorobkiem kursantów razem z nocnymi kopiami. Dane wróciły dobę później dzięki kopii, którą wsparcie AWS odnalazło poza panelem klienta. Nie zawiodło okienko z pytaniem o zgodę, bo destroy przepuścił człowiek, tylko plik decydujący o tym, czego ta komenda dotyczy.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Bezpieczeństwo · 4 min ·
Był czwartek, 26 lutego, kiedy Alexey Grigorev, założyciel DataTalks.Club, zobaczył na ekranie listę zasobów, których Terraform w ogóle nie powinien tworzyć. Przenosił akurat małą statyczną stronę z GitHub Pages do AWS, a narzędzie meldowało, że zaraz zbuduje od zera całe środowisko. Zatrzymał agenta i zapytał wprost, dlaczego powstaje tyle rzeczy naraz. Odpowiedź, jak sam opisał to potem na blogu, była prosta i przerażająca jednocześnie: Terraform był przekonany, że nie ma tam niczego.
Swój obraz świata Terraform trzyma w jednym pliku stanu i to ten plik, a nie konsola AWS, decyduje o tym, co narzędzie uznaje za istniejące. Grigorev przesiadł się chwilę wcześniej na nowy komputer i pliku nie przeniósł, więc terraform plan na czystej maszynie zameldował pustkę i zaplanował produkcję od nowa, a wykonanie planu ruszyło z włączonym automatycznym zatwierdzaniem. Udało mu się je przerwać, tyle że część zasobów zdążyła już powstać. Uprzedzę puentę, bo to dla mnie sedno tej historii: nie zawiodło tutaj okienko z pytaniem o zgodę na groźną komendę. Zawiódł plik, który decyduje o tym, czego ta komenda dotyczy.
Groźna była ta komenda, o którą nikt nie pytał
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.
