.env vs config files vs hardcoded best practices

[DHH]

Goedemorgen,

Ik ben bezig met een (Python) projectje waarbij ik data ophaal uit meerdere APIs en de data samenvoeg in een Azure SQL Server. Ik wil e.e.a. uiteindelijk via github publiceren, dus het is wel handig om de database credentials en API keys e.d. af te zonderen. M'n server, database, username en password komen daarmee in .env.

Voor het bouwen van een connectionstring maak ik gebruik van {ODBC Driver 17 for SQL Server}, maar als een toekomstige gebruiker ooit Driver 18 geïnstalleerd heeft, zal dat misschien ook wel gaan werken. De driver lijkt me daarom meer iets voor een config file i.p.v. een environment variable.

Het resultaat is dat je de connection string dan opbouwt uit een combinatie van config en .env, wat er naar mijn idee wel behoorlijk lelijk uit ziet. Werkt natuurlijk prima, maar het voelt ergens wel aantrekkelijk om die driver maar bij de credentials in .env te zetten zodat alles een beetje bij elkaar staat.

Ik ben nog een beetje zoekende in wat de best practices zijn op het gebied van .env files, config files en hardcoded. Ik verbaas me er soms over hoe druk ik me kan maken over dit soort triviale dingen, maar ben wel benieuwd hoe de meer ervaren programmeurs hier mee omgaan.

Misschien in het verlengde hiervan ook leuk om iets te zeggen over de best practices over het delen van de verwachte opbouw van een .env file (in mijn voorbeeld hierboven verwacht ik bijv. dat .env 'username' verwacht en niet (bijv.) 'dbuser'. Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen of meld je dit in je readme.md / andere documentatie?

[Kalentum]

Ik zou wel dbuser gebruiken omdat je env file meerdere usernames kan bevatten, bv een username voor een externe API ofzo

Een voorbeeld bestand met voorbeeld waarden is absoluut goed om er bij te doen

[ Voor 25% gewijzigd door Kalentum op 15-01-2022 13:49 ]

[MadGazelle]

Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen...

Ja. Wat ik meestal doe ik is een ".env.example" bestand toevoegen met alle variabelen die de applicatie verwacht. Indien nodig met default of voorbeeld values, resp. bijv. "FLASK_ENV=development" of "SECRET_KEY=insecure_key_for_dev"

... of meld je dit in je readme.md / andere documentatie?

Dat ook. In de readme vermeld ik dan onder de sectie 'Getting started' (oid) dat men de ".env.example" moet kopiëren, hernoemen naar ".env" en waar nodig de values moet aanpassen voor hun situatie.

[Morrar]

Ik gebruik ook vaak een default_config.yaml of iets dergelijks voor zulke dingen. Of in de docs zetten welke ENV variabelen gezet moeten worden.

Als je het echt chique will doen zou je zelfs nog een configuratie CLI kunnen bouwen. Via een script entrypoint in je setup.py is dat vrij simpel te implementeren. Eventueel met typer is het nog makkelijker.

[DHH]

Hoe zouden jullie dan omgaan met mijn voorbeeld van bijv. de driver? Het is geen 'groot geheim' dus m.i. hoeft 't niet in .env, maar het voelt wel weer lelijk om dat dan als enige 'connection' configuratie apart in een config bestand te zetten.

Ik heb het idee dat er niet echt een verkeerd antwoord is, maar ben benieuwd naar wat 'gangbaar' is.

[Kalentum]

Een .env is niet alleen voor secrets maar is voor alles wat je configureerbaar wilt maken. Dus die connection string kan ook prima in een env

[milo526]

Ik lees dat je met Python bezig bent, mijn achtergrond is meer JavaScript (NodeJS).
Hierin is het vrij gebruikelijk om een in een configuratie bestand, je environment variabele te importeren.
Vervolgens gebruik je door de applicatie je configuratie bestand (en dus nooit direct je environment variabele).

Wat hiervoor al genoemd wordt, je environment variables zijn om je omgeving in te stellen.
Niet alles hiervan hoeft noodzakelijk geheim te zijn.
De vraag is meer, wat wil je aan kunnen passen op andere omgevingen/servers.
Het is net zo zeer mogelijk om secrets in een config bestand te zetten, mits je dat config bestand niet meeneemt in je source control - hiervoor heb je dan weer een example bestand.

[onoweb]

alles in de config files en als er dingen in de config file "gevoelig" zijn of van veranderende aard per omgeving (dus niet mee mogen gecommit worden) dan steek je die in .env en verwijs je naar de env variabele in je config file.

[M0nkeymen]

Aangezien je DB op Azure staat en je python projectje misschien ook? Zou je ook Azure Key vault kunnen gebruiken.

[knarfyboy]

Doe m’n mongo db string gewoon in de env file. Ook omdat je per server allemaal flags kan hebben en anders moet je zo gaan rotzooien in de code.

[whoami]

Ik heb geen python achtergrond, maar wel een .NET / Azure achtergrond. Echter, ik denk dat dit eerder over een conceptueel iets gaat , dan iets wat specifiek toe te spitsen is op één technologie.

Eigenlijk moet je uw 'Config' zien als een verzameling van gegevens, en die gegevens kunnen van verschillende plaatsen komen. Je kan je Config opbouwen met gegevens uit een config file, uit environment variables of een .env file etc... Vanuit je applicatie ga je altijd het 'Configuration' object aanspreken om een config value op te halen, en nooit rechtstreeks de 'config-bron' gaan aanspreken.
Op die manier kan je uw configuratie zo opzetten dat je bepaalde config-values kunt gaan overschrijven.

In pseudo code zo je het zo kunnen beschouwen:

code:

var config = ConfigurationBuilder.AddConfigFile("filename")
        .AddEnvironmentVariables()
        .Build();

Zaken zoals connectionstrings, wachtwoorden, etc... komen bij niet in de reguliere config terecht. Die bewaar ik in een secret-store zoals bv Azure KeyVault.
Ik beschouw die zaken in mijn code ook liefst niet als gewone 'config values', maar ik wil die in mijn code ook als secrets gaan beschouwen. (Je zou nl. Azure KeyVault ook als een config-source kunnen toevoegen aan je configuration object).
Om dit onderscheid te maken, maak ik -in .NET dan- gebruik van de Arcus Security library, waarin een SecretProvider gedefinieerd is. Dit werkt dan gelijkaardig aan dat 'Configuration' object: Ik kan er ook verschillende 'sources' aan hangen: Azure KeyVault, maar ook Environment variables of zelfs mijn Configuration object. Op die manier maak ik in mijn code expliciet het onderscheid tussen 'configuratie' en 'secrets', en kan ik tijdens development op mijn workstation gewoon een .env file bijhouden waarin ik ook connectionstrings etc bewaar. (Die .env file gaat natuurlijk niet mee in source-control).
In productie zitten alle secrets mooi in KeyVault, en worden Configuration values opgeslagen in de Config van mijn Azure web App bv.

Als je een project opensourced, dan kan je idd een voorbeeld .env file meeleveren, maar meestal zet ik dergelijke dingen gewoon in de readme.md, evt met wat samples er bij. (Dat doe ik niet alleen voor open-source zaken, maar voor alle projecten die ik voor klanten doe).