We are creating a deployment of openSUSE clients with Salt. Kerberos needs password authentication. Therefore, we want to encrypt passwords before using them in Salt. I want to explain how to integrate that all.
At first, you have to install gpg, python-gnupg and python-pip. openSUSE wants to install only the package python-python-gnupg which isn’t enough for Salt. You have to use additionally pip install python-gpg.
After that, you have to create the directory /etc/salt/gpgkeys with mkdir. That will be the home directory for the decryption key of Salt. Then you can create a password less key in this directory. Salt is not able to enter any password for encryption.
# gpg --gen-key --pinentry-mode loopback --homedir /etc/salt/gpgkeys gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg2 --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Salt-Master Email address: sarahjulia.kriesch@th-nuernberg.de You selected this USER-ID:"Salt-Master <sarahjulia.kriesch@th-nuernberg.de>" Change (N)ame, (E)mail, or (O)kay/(Q)uit? O We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key B24D083B4A54DB47 marked as ultimately trusted gpg: directory '/root/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/6632312B6E178E0031B9C8E8B24D083B4A54DB47.rev' public and secret key created and signed. pub rsa2048 2019-02-05 [SC] [expires: 2021-02-04] 6632312B6E178E0031B9C8E8B24D083B4A54DB47 uid Salt-Master <sarahjulia.kriesch@th-nuernberg.de> sub rsa2048 2019-02-05 [E] [expires: 2021-02-04]
After that you have to export and import your public and secret key in an importable format. Salt can not decrypt passwords without the Secret Key.
# gpg --homedir /etc/salt/gpgkeys --export-secret-keys --armor > /etc/salt/gpgkeys/Salt-Master.key # gpg --homedir /etc/salt/gpgkeys --armor --export > /etc/salt/gpgkeys/Salt-Master.gpg # gpg --import Salt-Master.key gpg: key 9BE990C7DBD19726: public key "Salt-Master <sarahjulia.kriesch@th-nuernberg.de>" imported gpg: key 9BE990C7DBD19726: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 # gpg --import salt-master.pub gpg: key 9BE990C7DBD19726: "Salt-Master <sarahjulia.kriesch@th-nuernberg.de>" not changed gpg: Total number processed: 1 gpg: unchanged: 1
The key has the validity unknown at the moment. We have to trust that. Therefore, we have to edit the key, trust that, enter a 5 for utimately and save that.
# gpg --key-edit Salt-Master gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec rsa2048/3580EA8183E8E03E created: 2019-02-05 expires: 2021-02-04 usage: SC trust: unknown validity: unknown ssb rsa2048/4ABC9E975BD76370 created: 2019-02-05 expires: 2021-02-04 usage: E [ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de> gpg> trust sec rsa2048/3580EA8183E8E03E created: 2019-02-05 expires: 2021-02-04 usage: SC trust: unknown validity: unknown ssb rsa2048/4ABC9E975BD76370 created: 2019-02-05 expires: 2021-02-04 usage: E [ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y sec rsa2048/3580EA8183E8E03E created: 2019-03-07 expires: 2021-03-06 usage: SC trust: ultimate validity: unknown ssb rsa2048/4ABC9E975BD76370 created: 2019-03-07 expires: 2021-03-06 usage: E [ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de> Please note that the shown key validity is not necessarily correct unless you restart the program. gpg> save
So the key is validity and usable. You can see your keys listed with following commands.
# gpg --list-keys # gpg --homedir /etc/salt/gpgkeys --list-keys
Salt needs access to the key for decryption. Therefore, you have to change permissions on /etc/salt/gpgkeys.
# chmod 0700 /etc/salt/gpgkeys # chown -R salt /etc/salt/gpgkeys
We can decrypt passwords with the key now. Replace supersecret with your password and Salt-Master with the name of the key.
# echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r "Salt-Master" -----BEGIN PGP MESSAGE----- hQEMA0q8npdb12NwAQf+IuJgOPMLdsfHR1hGRPPkUPWaw7kbmRyMDT0VdGzCupQr +biaeIF2vuCjUn3RyI0t/E8GcBKUcsc1z7Xy22jAXl5c0pQNj0X9iK4ebpP5sHWc vdnn6J2KIKMe5lRsgcVmnZ9/yBssarpLLsw8SiPu1XofVmMjzRjQFONa2gpBe/5q hb/dSccP2f2kbDZ0Up12ntjUReyImn9/TLOsLOlQzEH0OGcJJXqk0SKP/HoH5+jJ FDMEZYWDhUyLdSwsa7RVB8tgFSQW8EJnehc2oLExKZ+ngW5hJfHI3l8N4IWv92ow bSvZsVaH+h8epCOLgiYQsiWBJ/dWl1ZQx+tmHfAtT9JFAbk/gbeOfZ8RboX2JvRv h7semDNEYxqG8zusn8JykzivV37DERixR8nbh1XQDsOF5l0AmIrdJB6dvGW88tR+ ei2ij0QM =rl1+ -----END PGP MESSAGE-----
The output is a Base64 encoded PGP Message. You can use that in your sls file (in my case kerberos.sls) in the pillar directory.
kerberos: principal: X95A password: | -----BEGIN PGP MESSAGE----- hQEMA0q8npdb12NwAQf+IuJgOPMLdsfHR1hGRPPkUPWaw7kbmRyMDT0VdGzCupQr +biaeIF2vuCjUn3RyI0t/E8GcBKUcsc1z7Xy22jAXl5c0pQNj0X9iK4ebpP5sHWc vdnn6J2KIKMe5lRsgcVmnZ9/yBssarpLLsw8SiPu1XofVmMjzRjQFONa2gpBe/5q hb/dSccP2f2kbDZ0Up12ntjUReyImn9/TLOsLOlQzEH0OGcJJXqk0SKP/HoH5+jJ FDMEZYWDhUyLdSwsa7RVB8tgFSQW8EJnehc2oLExKZ+ngW5hJfHI3l8N4IWv92ow bSvZsVaH+h8epCOLgiYQsiWBJ/dWl1ZQx+tmHfAtT9JFAbk/gbeOfZ8RboX2JvRv h7semDNEYxqG8zusn8JykzivV37DERixR8nbh1XQDsOF5l0AmIrdJB6dvGW88tR+ ei2ij0QM =rl1+ -----END PGP MESSAGE-----
Salt is not able to distinguish encrypted from non-encrypted strings at the moment.
You have to uncomment the entry gpg_keydir: and add /etc/salt/gpgkeys in the salt-master configuration of /etc/salt/master. In addition, you can find the part with decrypt_pillar:. In my case, I add – ‚kerberos:password‘: gpg there.
You need a restart of the service salt-master. Afterwards Salt knows, that the special pillar entry has to be decrypted with gpg. Following you can run the sls file on any salt client and Salt can use the password.
At the end you should remove the command with your password for the PGP Message creation in your bash history. Therefore, edit ~/.bash_history and remove the entry with echo. So nobody can figure out the secure encrypted password for the user.
I wasn’t aware of the decrypt_pillar config option, but having to list each encrypted value there sounds a bit 😉 annoying if you have lots of encrypted values.
The way I use is to have the encrypted pillar in a separate file which has „#!yaml|gpg“ as its first line.
I tried that at first, too. That didn’t work as expected. Then I tried it with the list. You don’t need the shebang line if you are using the master config. Both methods are possible.