How to pass sensitive data to a command in a cmd.run state

[merlinz01]

I am needing to run a command that takes a password either from stdin or a file specified as an argument. What is the best way to do this without exposing the password unnecessarily?

Here are the options I have come up with:

• Use file.managed to write the password to a file and require that in my cmd.run state. I could then use file.absent to remove it, but then it would always show that a state changed.
• Set the password as an environment variable and do something like echo $THEPASSWORD | thecommand --password-file /dev/stdin. This has the security problems associated with environment variables, but at least it doesn't ever leave the password file lying around.
• Add an option to cmd.run to do this sort of thing.

Am I missing a better idea?

[nicholasmhughes]

It's possible that the last bullet is the best choice.

The first one is definitely problematic from (at least) an idempotency standpoint. You might be able to set requisites such that the password file won't be written under certain circumstances, but it's a little hacky.

The environment variable route could work, but it has a pretty big leak exposure since anyone who can render the state could see the actual password substituted in the state block.

mycommand:
  cmd.run:
    - name: "echo $THEPASSWORD | thecommand --password-file /dev/stdin"
    - env:
      - THEPASSWORD: "{{ pillar.get("thepassword") }}"

In lieu of creating a new option for cmd.run that handles this scenario, you could potentially use slots...

mycommand:
  cmd.run:
    - name: "echo $THEPASSWORD | thecommand --password-file /dev/stdin"
    - env:
      - THEPASSWORD: __slot__:salt:pillar.get(thepassword)

...which would get around the problematic rendering issue and force the "getting" of Pillar data to runtime.

Although, this really feels similar to Kubernetes separates Environment Variables and Secrets... handling each in a different way to mitigate this issue. I personally wouldn't be opposed to that route, but slots probably get you the best solution without trying to get a feature merged.

[merlinz01]

Thanks, I hadn't seen the slots feature before. I also just discovered that the cmd.run state accepts more options than are documented, including a stdin option, which is perfect to use in conjunction with the slots feature. So we end up with this proof-of-concept:

fancy little trick:
  cmd.run:
    - name: rev /dev/stdin
    - stdin: __slot__:salt:test.echo("hello there")

resulting in

local:
----------
          ID: mycommand
    Function: cmd.run
        Name: rev /dev/stdin
      Result: True
     Comment: Command "rev /dev/stdin" run
     Started: 18:54:14.194017
    Duration: 9.259 ms
     Changes:   
              ----------
              pid:
                  2023192
              retcode:
                  0
              stderr:
              stdout:
                  ereht olleh

Summary for local
------------
Succeeded: 1 (changed=1)
Failed:    0
------------
Total states run:     1
Total run time:   9.259 ms

This is perfect because it leaves no possiblility of leaked environment variables or password files.
I'll see about opening a PR to better document the cmd.run state, maybe even mentioning this trick.

EDIT: I see now that the state documentation does mention that more options are available than listed.

EDIT: For the sake of any who read this, this works but beware of permission errors as described in the following discussion. Depending on the command, you might be able to use "-" or a command line flag instead of /dev/stdin, which should fix those errors.

[merlinz01]

So now I'm running into this error when I specify the runas option:
cannot open /dev/stdin: Permission denied
I see the command is being run in a chroot jail and that this /dev permission error is common for chroot jails; does someone have a solution?
I suppose I could run without the runas option but then I would have to make sure the produced files have the right user and group.

[nicholasmhughes]

Reproducible from bash:

root@u22-party-01:/srv/salt# echo "hello" | su -s /bin/bash - ubuntu -c "rev /dev/stdin"
rev: cannot open /dev/stdin: Permission denied

You can get around the issue with the -P switch:

root@u22-party-01:/srv/salt# echo "hello" | su -P -s /bin/bash - ubuntu -c "rev /dev/stdin"
hello
olleh

But unfortunately it doesn't seem that we can pass that switch through from the state. This particular problem probably warrants a bugfix ticket.

[merlinz01]

So when I run this state, rev hangs waiting for more input:

using the pty flag:
  cmd.run:
    - name: su -P - myuser -c "rev /dev/stdin"
    - stdin: hello there

When I kill the rev process, the state returns showing the original stdin. So I think it has to do with the pseudo-terminal (or Salt?) not forwarding stdin.
However, I can run echo hello | su -P - myuser -c "rev /dev/stdin" as a cmd.run state without it blocking, but that isn't what I want to do.

[merlinz01]

So I am coming to understand that the only way to combine reading from stdin and running as a different user is for the command to read from the internal stdin file descriptor (not try to open /dev/stdin). The command I am trying to run (step) has an open PR that should make it read from stdin when "-" is passed as the password file. For now I'll have to just run as root and then update the owner and group of the output files.