Re: [salt-users] cmd.script or cmd.run & masking passwords

[Colton Myers]

I would recommend using Pillar [1] to store the passwords and then run the script through the jinja templating system in salt to populate those passwords on the minions (use the `template` arg in the cmd.script function).

[1]: http://docs.saltstack.com/topics/pillar/index.html

--

Colton Myers

On Tue, Nov 5, 2013 at 11:15 AM, <robert...@gmail.com> wrote:

Hi,

 

I am currently testing Salt to see if it meets our requirements for automation & deployments. I'm envisioning running our deployment scripts via cmd.script called by a state file. Some of the commands in these scripts use several different passwords as arguments for one command.

 

Is there anything salt provides to hide/mask/encrypt passwords in scripts or commands? We cannot store passwords on the filesystem unencrypted. Looking for something similar to what RunDeck provides in that regard, or any other work-arounds.

 

How does everyone deal with that?

 

Thanks,

Robert.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Colton Myers]

The best option here is probably to choose an encrypted medium to store the passwords and use an external pillar module that decrypts and loads them.  Would this work?

--

Colton Myers

On Wed, Nov 6, 2013 at 11:45 AM, Robert Czire <robert...@gmail.com> wrote:

Thanks Colton for your input. I'm aware of Pillar, but at the end of the day that still stores the password in clear text. That's what I'm trying to prevent.

Thanks,

Robert.

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/EXxNLUIWs8E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Robert Czire]

In theory, yes. Though I'm not aware of any such product besides a security appliance for key storage. I'll research that a bit, and happy to hear more on this.

Also playing around with the idea of using Rundeck as a wrapper around Salt, which has some facilities for protecting passwords (not yet sure how secure) and would also centrally log all executions by default. 

This is not ideal, but already have Rundeck and might do the trick until (hopefully) we have some options within Salt or find a better alternative.

Thanks,

Robert.

[Colton Myers]

Keep us posted!  We'll be interested to see what you come up with.

--

Colton Myers

[Brandon Matthews]

Robert,

There are two types of passwords: those you must present (you are the keyholder), and those you must validate (you are the doorknob owner).

Much like inspecting a doorknob does not necessarily give you the shape of the key, cryptography is useful when other services are presenting shared secrets to you. You don't need to know the shape of the key in order to provide the doorknob. Similarly, you only need to keep a cryptographic hash around in order to show that the password presented is correct.

If you are the keyholder, though, you must somehow always have knowledge of the key's shape available. If it wasn't available, you wouldn't be able to present it! You can put your key in a locked box, but that box also has its own key. How do you store that box's key? If you're presented with a doorknob, you can make it harder to present your key, but ultimately it must be presented in its "bare" form.

If you encrypt your passwords, the encryption key must be stored somewhere. If you encrypt *that* key, your key-encryption key must be stored somewhere, too. If you have a central vault to store encryption keys, anyone who wants to extract a key from your vault must present their own password. How are those passwords stored? What is the process for automating their use? It really is turtles all the way down.

The lesson is that either a) a person must be involved to provide the shared secret, or b) the shared secret must be stored in a directly machine-readable format. You will need to build security by means of secure transmission, appropriate filesystem permissions, proper handling procedures, and regular access control review.

Good luck!

Brandon

[robert...@gmail.com]

Hi Brandon,

 

thanks for your detailed response. I may have failed to mention that I'm not looking for a fully automated solution, only to NOT have to store passwords unencrypted on the file system, which as you know is a pretty basic security practice. To follow your analogy, I'm happy to carry a key and present it, I just don't want it duct-taped to my doorstep in plain view :).

 

It would be really cool if there was a builtin option within Salt to encrypt certain Pillar data (maybe with the master's key), and have it decrypted in flight to the minion. That would solve the problem of not storing passwords in cleartext.

 

As far as I understand, Salt commands don't support prompting for input either during run-time as commands are basically dispatched to the minion without returning prompts. If that weren't the case, it would also solve the problem.

 

For now I have configured Rundeck (opensource command execution system minus Salt's config management) to execute the salt commands on the Salt master and pass the appropriate passwords as options. Rundeck has a secure password option that obscures the password when configured in a job, though not entirely sure yet where/how the passwords are actually stored. In this way the passwords aren't visible and the only thing I need to make sure of is that no one turns up logging on the minion which would expose the actual commands being executed along with the passwords. This seems to work for now, but adds the unsavory complexity of having to use one command execution system to dispatch commands to another. Still, Salt is a great product and I hope to find a better way soon.

 

Thanks,

Robert.

[Luminous Salt]

On 2013-11-07 12:05, robert...@gmail.com wrote:
> Hi Brandon,
>
> thanks for your detailed response. I may have failed to mention that
> I'm not looking for a fully automated solution, only to NOT have to
> store passwords unencrypted on the file system, which as you know is a
> pretty basic security practice. To follow your analogy, I'm happy to
> carry a key and present it, I just don't want it duct-taped to my
> doorstep in plain view :).

I'd prefer an automation solution which lets me do what I need to. So,
as long as I have the flexibility to do what I need, and get help along
the way.. I'm happy.

In this case, you have all the flexibility you need (see below).

> It would be really cool if there was a builtin option within Salt to
> encrypt certain Pillar data (maybe with the master's key), and have it
> decrypted in flight to the minion. That would solve the problem of not
> storing passwords in cleartext.

While salt does not do this for you, you have everything you need to do
it rather simply.

For example, you could.. setup postgres to encrypt what you care about,
create a module to encrypt/decrypt and use postgres for storage, then
pull in this data as an external pillar.

You could do this differently such that it isn't in pillar, and run the
module on the minion itself (as opposed to on the master, where pillar
is collected).

> For now I have configured Rundeck (opensource command execution
> system minus Salt's config management) to execute the salt commands on
> the Salt master and pass the appropriate passwords as options. Rundeck
> has a secure password option that obscures the password when
> configured in a job, though not entirely sure yet where/how the
> passwords are actually stored. In this way the passwords aren't
> visible and the only thing I need to make sure of is that no one turns

Security by obscurity isn't security.

As you've noted, you're not 100% sure what is actually happening behind
the scenes. So, as I see it, your ignorance here appears ok because
rundeck at least hides the sensitive detail you care about from the
frontdoor.. but anyone who is determined to get into your network and to
your data will definitely poke around more than just the frontdoor, so
that ignorance _may_ bite you later on. Not attacking rundeck, just
noting the lack of strength in this reasoning.

[robert...@gmail.com]

Hi Luminous salt,

 

those are interesting ideas. I am new to Salt so can't judge how feasible they are right off, but I'm willing to learn and explore :). If the pillar module can prompt for a password to decrypt the sensitive data from postgres, that would do the trick. I'm not sure how a module would work on the minion though. As to your comment on security by obscurity, I agree, that isn't security. To my case, I am actively researching how Rundeck stores its passwords not just turning a blind eye (you may have noticed the "yet" in my post). If I find that it doesn't store them securely, the solution won't make it past my POC.

 

Thanks,

Robert.