Sprytne sposoby pozbycia się z kodu wrażliwych danych przed oddaniem pod kontrolę kodu.

0

Ciekawi mnie, jakie triki stosujecie, aby zapobiec udostępnianiu wrażliwych danych (credentiali, nazw tajnych/poufnych etc.), gdy macie nimi napaćkane w projekcie, a usuwanie całego tego bałaganu z palca jest niesamowicie nużące. Któryś raz łapię się w sytuacji, gdzie rozwijałem sobie coś na prywatnym repo, działa już w miarę fajnie, ale chciałbym udostępnić wersję pozwalającą na przeglądanie tych moich wypocin.

Tym razem postanowiłem przerzucić wszystkie takie dane do plików .properties (Java, Spring), ale pomyślałem że pewnie są jakieś alternatywy do takiego postępowania. Help, bo jestem naprawdę głodny wiedzy

3

Jedyna skuteczna metoda to nigdy nie wrzucać. Nauczyłem się tego kilka razy przepisując historię w istniejących repo (nie tylko swoich).
Zazwyczaj robię sobie jakiś folder ./etc ./tmp który leci od razu do .gitignore. W zasadzie to jedyne konfiguracje, które trzymam poza kodem (scala, kotlin).
Inna sprawa, że wiele tam nie ma - zazwyczaj jakieś sekrety oauth itp.
Na githubie takie rzeczy wpadają później jako secrets (żeby np. deployować kod na chmurze).

4

Nie do końca rozumiem problem. U mnie takie rzeczy jak credntiale z definicji są wyciągniete do properties bo jak odpalam sobie testy to uzywam zupełnie innych properties niż jak aplikacja jest gdzieś deployowana (np jakaś baza in-memory zamiast normalnej bazy).

2

Jak już są takie babole w repo, to raczej zostaje tylko je usunąć razem z całą historią commitów, która była do tej pory i dopiero wtedy pchać do zdalnego repozytorium.
Ale żeby nie musieć się tego obawiać po prostu zawsze korzystam z plików konfiguracyjnych, a wrażliwe informacje, takie jak connection string do bazy, albo jakieś klucze do zewnętrznych usług wstawiam do zmiennych środowiskowych, lub do UserSecrets (piszę w .NET) i tak piszę appkę, żeby przy starcie łączyła konfiguracje z ENV i UserSecrets i konfiguracji z plików konfiguracyjnych projektu.

2

Jak już popełnisz ten błąd, że wrzucisz jakieś credentiale na brancha (mam nadzieję, że nie master bo będzie niewesoło) to nie zapomnij zrobić squash'a, żeby w historii commitów nie zostały :P
A tak na serio to albo properties'y albo zmienne środowiskowe (tylko jeśli credentiale są stałe)

5

Tu może mała uwaga. Myślę, że OP wie co to są propertiesy - tylko, że w propertiesach też można mieć "drażliwe" dane, a propertiesy się commituje. Tyle, że nie wszystkie - tu sobie trzeba ułożyć strategię.

0

Dzięki za szybkie odpowiedzi :) Wasze rady są cenne i prawdziwe, jednak w sumie nie wspomniałem jawnie, że chodzi mi o pet projecty. Nie jestem w sytuacji, że po roku projektu na produkcji nagle się zastanawiam z resztą teamu, czy to nie przesada, że trzymamy te wszystkie hasła w source'ach. Chodzi mi o projekty, które tworzę dla zabawy, dla siebie, ewentualnie dla jakiegoś znajomego, który sobie z tego korzysta. Nie znajdują się tam raczej też realne loginy, hasła i inne takie wrażliwe. Po prostu wzbudziła się we mnie ciekawość, jak inni programiści decydują się zgrabnie zagryzać temat właśnie czegoś takiego.

0

Dla pet-projectów zwracanie uwagi na takie rzeczy jest nawet ważniejsze i tym bardziej przeglądam po 3 razy każde miejsce, gdzie łączę się z bazą lub zewnętrzną usługą, bo w pracy to jest szansa, że takie coś wyjdzie na code review, albo potem i tak sporo firm ma różne procesy na zapobieganie temu, i prawie na pewno mają dobre monitorowanie kosztów zużycia usługi itp.
A ponieważ w prywatnych projektach coraz częściej używamy np. chmury, to przypadkowe wrzucenie klucza do AWSa, którego używasz na defaultowych ustawieniach, bez ustawionych limitów wydatków, może wymagać potem sprzedaży co cenniejszych rzeczy w domu, żeby zapłacić rachunek od Amazona ;)

0

W środowiskach gdzie był nacisk na security, było tak:

  1. hasła przechowywane w keystore
  2. proces dostaje lokalizację keystora i przy starcie pyta o hasło (w wersji hard) do tegoż keystore'a, zaś w wersji nieco lżejszej zaczytuje z pliku/zmiennej środowiskowej
  3. proces wyciąga hasła z keystora i coś tam dalej z nimi robi

Im większy nacisk na security, tym rozwiązanie mniej przyjemne w utrzymaniu (restart procesu -> Podaj hasło, zmiana hasła itp.).

2

Zawsze możesz dorzucić pre-commit hook żeby wyłapywać takie rzeczy. Szybkie googlowanie i znalazłem coś takiego https://github.com/Yelp/detect-secrets

0

Nie korzystam z credentiali do "proda" u siebie lokalnie, leżą sobie gdzieś na AWSie (jeśli akurat IAMem tego nie ogarnę od palca, to jest parameter store za free) albo jako zmienne środowiskowe w CICD (np żeby w ogóle na AWSie coś ruszyć w infrastrukturze). Zamiast takiego podejścia "pull" z parameter store które jest mimo wszystko lekko upierdliwe, można też sobie sklejać pliki dla konkretnego środowiska w CICD. Nie muszę chyba mówić że jeśli w CICD sekret wycieknie (na przykład user dla terraforma), to całe twoje konto stoi otworem (mam na myśli bankowe, przed AWSem).

Jeśli taki bubel zostanie wcommitowany, to polecam od razu zrotować sobie ten sekret, wtedy nie trzeba się zastanawiać czy przypadkiem seria twoich amendów i rebaseów nie zostawiła po tych kredkach jakiegoś śladu. Upierdliwe, ale to jedyna pewna metoda.

0

W .NetCore masz do tego pliku secrets.json.

0

W serwisie springowym możesz przekazać dane jako:

  • parametr uruchomieniowy
  • zmienną środowiskową
  • podpiąć zdalny key vault (i ewentualnie przekazywać hasło do niego jedną z powyższych metod)

Lokalnie dopisujesz sobie w IDE wartości sekretów jako parametry uruchomieniowe, a jeśli chodzi o produkcję dorzucasz wartości podczas budowania pajplajnem, gdzie sekrety są przechowywane na poziomie serwera CI.

0

W pet projektach jest to zupełnie nieistotne. W prawdziwym projekcie powinieneś nie móc i tak tego zrobić bo korpo dba o swoje sekrety. Chyba że jesteś kimś wysoko kto powinien mieć dostęp do sekretów. Ale skoro pytasz to nie jesteś.

6

Pet project czy nie, credentiali NIGDY nie wrzuca się do repo. Jeśli to pet project to pewnie masz jakiś serwer, na którym masz różne rzeczy, więc to się może odbić czkawką, a jak jeszcze Ci jakieś kredki do AWS w ten sposób wypłyną to się możesz obudzić z niezłym rachunkiem do zapłacenia.
Swoje projekty (głównie PHP i trochę Node) zazwyczaj organizuję tak, że każdy projekt ma swoją konfigurację dockerową na lokalu. Hasła do lokalnego developmentu mam ujednolicone zazwyczaj coś w stylu root/docker, i je trzymam w plikach typu .env. Plik ten nie jest commitowany do repo, ale mam jego kopię .env.dist i tam sobie trzymam wszystko dla środowiska dev - jak developer stawia to po prostu sobie kopiuje .env.dist na .env i ma temat hasła ogarnięty. Plik .env z danymi produkcyjnymi trzymam jako zmienną w CI/CD i jest on wgrywany w czasie deployu.
Co się da staram się ogarniać za pomoc zmiennych środowiskowych i wtedy analogicznie mam plik z .env dla docker-compose.

Trzymanie haseł w repo to jest bardzo zły pomysł ZAWSZE bo nigdy nie wiesz czy kiedyś kodu nie będziesz musiał komuś pokazać, a jak ktoś ogarnia gita to te hasła sobie wykopie z historii.

1 użytkowników online, w tym zalogowanych: 0, gości: 1