Då vi vill exponera så mycket som möjligt av våran kod är tanken att vi endast arbetar i ett publikt repository på github.

Detta innebär att vi måste vara disciplinerade samt ha säkra rutiner när det kommer till att inte exponera interna lösenord, API-tokens, nycklar osv. Vi bör alltid spara känslig information m.h.a Centraliserad konfiguration och använda .env -filer lokalt.

tl;dr; Lägg aldrig känslig information i koden, inte ens för ett snabb-test, då kommer den garanterat att pushas till Github (vis av erfarenhet).

Nytt repository

Vid skapandet av ett nytt repository bör detta vara satt till “private”, sätt om det till “public” först när vi känner att det vi vill dela med oss av är någorlunda stabilt.

Keystores / certifikat

Dessa bör inte ligga i koden/tjänsten, även om de är lösenordsskyddade och lösenorden är centraliserade. Varje tjänst bör ha en egen mountad volym där keystores och certifikat kan ligga. Då de ändå bör versionshanteras kan de ligga i vår interna gitlab.

Skulle någon råka committa och pusha ett lösenord tillsammans med t.ex. ett certifikat gör det ingen skillnad om lösenord byts, certifikatet går fortfarande att använda tillsammans med lösenordet i just den committen.

I detta fall skall ett nytt certifikat beställas.

Hur fort det går från att en push av en secret tills dess att den faktiskt börjar utnyttjas kan läsas i den här twittertråden https://twitter.com/andrzejdyjak/status/1324360905237372929?utm_campaign=32&utm_content=226&utm_medium=cio&utm_source=email . Kortfattat tog det ca 1 h innan den komprometterade datan började nyttjas.

Personuppgifter

Om olyckan är framme

Råkar vi pusha ett lösenord, token eller liknande till github skall detta ses som att det har läckt. Det går inte att rädda det genom t.ex. en force-push då informationen redan kan ha fångats upp av 3:e-part.

Rensa en commit från ett repo

Även om lösenordet måste bytas ut i källan (WSO2/Databas/whatever) kan det ändå vara snyggt att inte ha kvar det i koden.

Ligger koden på branch är det enkelt att göra en interactive rebase mot main/develop, ta bort innehållet, alternativt squasha ihop committen och force-pusha.

Eller:

Rensa en commit m.h.a. BFG-cleaner

Är det en commit som ligger “långt ner” i historiken, eller kanske en fil som måste rensas ur varje commit är det enklare att använda detta verktyg: https://rtyley.github.io/bfg-repo-cleaner/

Verktyget kan ta bort
Värt att tänka på är att detta kommer skriva om historiken i repositoriet, dvs. alla som jobbar med samma repo måste checka ut repositoriet på nytt och ta bort alla gamla kloner.

Dokumentationen på sidan är bra men i korta drag gör man följande:

1. Klona repositoriet med --mirror-flaggan

2. Kör bfg-cleanern med det/de kommandon som behövs.

3. Gå in i “.git”-mappen och kör:
   git reflog expire --expire=now --all && git gc --prune=now --aggressive

4. Pusha ändringarna.

OBS! BFG-cleaner ändrar inte innehållet i den senaste committen, ligger det känslig information i den måste det rättas till “manuellt”.

TODO

• Utred Github Enterprise för:

  • git-pre-push-hook som kan identifiera dom vanligaste förekomsterna av lösenord, certifikat m.m. och på så vis neka en push.

• Ta fram rutin för hur certifikat hanteras i docker m.h.a. mountade volymer

• Gitguardian?