Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Our pool CSV has a plaintext password column and security review flagged it, fairly. Options I can see are all bad:
Is there a fourth thing?
Accepted answer
There is. Cell values are interpolated the same way configuration is, so a password column can hold a reference instead of a value:
id,username,password,role,displayName
1,Heath93,${RWA_PASSWORD:-s3cret},standard,Ted ParisianThe file stays committed, reviewable and diffable, and the actual secret comes from .env, .env.<env> in the repo root or the project directory, or from the real environment in CI.
The :-default form is worth using deliberately. For a public sandbox the default is the demo credential and the file works out of the box. For a real environment, leave the default off so an unset variable is loud rather than wrong.
sdods data preview shows you the file, not the resolved row, so what you see is the placeholder:
The same rule is enforced in the yaml — a key that looks like a secret with a literal value is a CONFIG_SECRET_LITERAL error, so env.vars.standardPassword: hunter2 will not resolve at all. The data files are the one place you can still do the wrong thing by hand, so review for it.
What we settled on, if it helps: the committed CSV carries only ids, usernames, roles and display names, and every password cell is the same ${QA_ACCOUNT_PASSWORD} reference. The accounts are provisioned by a seeding script that sets them all to that one value in the test environment.
It means the CSV tells you nothing an attacker wants and still runs unchanged on any machine that has the variable.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.