Env vars treated as secrets

[rahfar]

Hi,

In regard to the impossibility of #182, I am wondering if it is possible to add a flag option to the CLI that would make env vars be treated as secrets?

My case - load_secrets.sh && spot, where load_secrets.sh script export secrets as env vars, so they would be accesable to spot playbook.

Or maybe an option for setting secrets from env..

[umputun]

i wonder what the use case for such functionality. I mean, If you want secrets to stay encrypted using the builtin "spot" provider storing them in sqlite seems to achieve the same goal. This load_secrets.sh you mentioned can just call spot-secret set ... and will populate it to secrets db, either external one or the embedded sqlite. If you don't care about encryption - simple env values will do

Making a new secrets provider for flat file is possible, and this is somewhat similar to what ansible provider is doing already. But I don't really get why this thing is needed and what exactly you expecting to store in such a file.

[rahfar]

If you don't care about encryption - simple env values will do

To clarify myself, maybe I got used to how env vars are handled by docker compose - you can specify them with value:

- MYVAR=123

or without value

- MYVAR

and in this case it would be read from environment of the command that runs docker compose.

In spot there is only first option as I understand. So I have to dump env vars in env.yml or spot.db, but it would be handy if lets say by deafult, if there is no secret provider specified, secret with name MYSECRET would be just read from env var MYSECRET

Making a new secrets provider for flat file is possible

No no, agree with you that it makes no sense - to store secrets in plain file

This load_secrets.sh you mentioned can just call spot-secret set ... and will populate it to secrets db, either external one or the embedded sqlite.

Thanks, that acctualy looks like a most likely option that I will use - load_secrets.sh && spot ...; rm spot.db

[umputun]

and in this case it would be read from environment of the command that runs docker compose.

yeah, I have thought about allowing system env to be passed into the spot to both command line and from via file. The cnange is trivial and probably make sense. I'll see what I can do about it. This is likely going to be more explicit syntax like MYVAR=$BLAH to keep int consitent between the file and cli

[rahfar]

@umputun , spotted similar discussion about ansible https://serverfault.com/questions/681832/how-can-i-stop-ansible-from-writing-passwords-to-the-logfiles

What do you think about the idea of having a similar task-level option, no_log: true?

With this I could pass secrets directly as env vars, without need to call spot-secret and defer rm spot.db

[umputun]

I don't like it for a few reasons:

1. no_log options sounds too strict. Users may have a valid reason for logging, for example to debug the playbook.
2. This option may not be sufficient to prevent leaking of such secrets - someday some PR will add a debug statement and I could miss it; doesn't sound like a reliable way to hide info to me.
3. Setting it on task level also not a reliable way to ensure it is hidden for real as some other task may echo it by accident or intentionally.

The current way to mask secrets is much more reliable because it prevents logging them on the lowest level possible (log itself) regardless of what task is running and how exactly the information is printed. To me, the preferable solution would be to introduce some way to mark some env keys as "sensitive". I'm not sure what the right syntax for this. Can be GH action's style, i.e. secret.blah implicitly treating all env vars with secret. prefix like the rest of secrets or a new top-level element (not even sure what it should be called, maybe secret_env) with a list of env var names.

[rahfar]

Yes, I agree with you. I will also review how it is done in other tools. But for now, let's wait to see if anyone else has such a use case.