Password Security with GPG in Salt on openSUSE Leap 15.0

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.