0

I would like to have the following a bit more clean. I'm trying to create concatenated CA file using Salt. To accomplish this I first have to collect all glusterfs.pem files from all my minions and transfer them to the salt-master's minions cache and then output all glusterfs.pem into a single CA file (glusterfs.ca) on the salt-master to later on enroll them again on all minions.

Actually my solution is working but it is simply out of the salt context and looks crappy to me. I'm new to salt, I never worked with reactors, so and I was hoping to find some help (preferably with an example if possible) on this site.

This is my current situation only using states:

glusterfs/init.sls (only runs on minions)

/etc/ssl/glusterfs.key:
  x509.private_key_managed:
    - order: 9
    - bits: 2048
    - name: /etc/ssl/glusterfs.key

/etc/ssl/glusterfs.pem:
  x509.certificate_managed:
    - order: 10
    - signing_private_key: /etc/ssl/glusterfs.key
    - CN: {{ grains.id }}
    - C: UA
    - ST: Unavailable
    - L: Unavailable
    - basicConstraints: "critical CA:true"
    - keyUsage: "critical cRLSign, keyCertSign"
    - subjectKeyIdentifier: hash
    - authorityKeyIdentifier: keyid,issuer:always
    - days_valid: 3650
    - days_remaining: 0

/etc/ssl/glusterfs.ca:
  file:
    - order: 11
    - managed
    - source: salt://glusterfs/glusterfs.ca

ca.sls (only runs on salt-master):

collect_glusterfs_certs:
  cmd.run:
    - order: 1
    - name: salt -C 'not salt' cp.push /etc/ssl/glusterfs.pem

concatenation_glusterfs_certs:
  cmd.run:
    - order: 2
    - onlyif: 'test ! -e /var/cache/salt/master/minions/{master*,worker*}/files/etc/ssl/glusterfs.pem && test ! -e /srv/salt/glusterfs/glusterfs.ca'
    - name: 'cat /var/cache/salt/master/minions/*/files/etc/ssl/glusterfs.pem > /srv/salt/glusterfs/glusterfs.ca'

I basically first pull all glusterfs.pem to the local salt-master's minion cache and afterwards create the concatenated glusterfs.ca file which I later deploy onto all the minions I previously collected the glusterfs.pem file from...

Thanks in advance

0

It feels like what you have done here is implement a discount/bastardized CA (Certificate Authority). I fear that in doing so, you might have inadvertently created a security threat for yourself.

In a traditional PKI deployment, your client would generate a private key and a Certificate Signing Request (CSR) that is then submitted to your Certificate Authority for signing. Your CA would then sign your key after validating the applicant by some means and issue a Certificate to be installed on the client.

What you may have just done by concatenating every single certificate of each client into a CA is grant each and every client the ability to sign certificates for other machines. Any machine in your Gluster cluster then may have the ability to issue a certificate for an arbitrary key which then would be trusted by your Gluster cluster which could allow for an attacker to use a compromised system or key to allow an arbitrary endpoint to join your cluster.

Instead, you might want to follow this guide on setting up a CA for use by your SaltStack. In fact, it is worth noting that your salt master is itself a CA. You could simply copy the minion's certificate and key for use by gluster, though that has the downside of a compromised cert/key being able to be used to impersonate a minion.

But generally speaking, you probably don't want to grant all of your minions the power to be a CA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.