#3355 fedmsg needs a CA
Closed: Fixed None Opened 11 years ago by ralph.

= We need a CA =
We need a certificate authority for fedmsg and a way to issue certs/keys for
each service. We'll also need a place for the CRL. And finally, we also need a good plan for setting up read access for the keys where they're needed.

= Some explanation =
The requirement is that we need to be able to guarantee that a message comes
from where it ought to come from. We do not need (and do not want) to encrypt
the messages.

Originally, I looked at using the existing puppet certs. I wrote some code to sign and validate messages here -- https://github.com/ralphbean/fedmsg/pull/38 -- it works!

The blocker is that any service sending messages would need read access to puppet's private key which is not acceptable.


Well, for openvpn we currently use it's 'easyrsa' set of scripts.

http://openvpn.net/index.php/open-source/documentation/miscellaneous/77-rsa-key-management.html

It's a very simple set of scripts.

Perhaps we could just reuse this for fedmsg?

We would setup a new dir in the private repo, puppet could then put any certs/keys in place.
We could expose the crl and such in the http://infrastructure.fedoraproject.org/something/ space for anyone to pull crl or other public side info.

Thoughts?

Yes, that looks good to me.

The last part of my initial question is still a little fuzzy for me: what is a sensible scheme for read access to private keys on service hosts.

For instance, we need a cert/key pair for bodhi on app01.stg, app02.stg, ... etc.

We also need a cert/key pair for mediawiki on app01.stg, app02.stg, ... etc.

Both services run as apache, so both private keys will need to be readable by apache and we've lost some of the separation that we thought we'd gained by issuing distinct cert/key pairs to each service. If mediawiki is compromised, it can send messages as bodhi.

Services like koji, scm, and zodbot all run (or likely run) as distinct users, and so can have their keys separated nicely. Any ideas for what to do about apache processes?

Things run by mod_wsgi do not need to run as apache. fas and mirrormanager both appear to be configured to run as a different user. We'll need to make sure that we're setting up those user's and groups on the boxes.

php apps may all need to run as apache... I'm not sure if there's any secure means of running those as another user.

That seems sufficient to me. mediawiki is the only php app in infra that I can think of; at very least it is the only fedmsg-enabled php app on my radar.

Ok, I scripted the creation of a ton of cert/key pairs for all the services ready for fedmsg in stg up to this point. They're living in my homedir on lockbox in {{{~/easy-rsa/2.0/keys}}}.

They layout of the private repo is a mystery to me, but if someone could copy them there, I imagine I can setup a puppet config to distribute them to the right places. I'll just need to know their relative path in the private repo (I think).

More updates:

  • Here's a SOP explaining what's going on and how to maintain certs:
    http://infrastructure.fedoraproject.org/infra/docs/fedmsg-certs.txt
  • The keys are now in my homedir on lockbox in {{{~/fedmsg-certs/keys/}}}.
  • They have been separated from the management scripts (modified easy-rsa). Those script have been placed in puppet in {{{puppet/modules/fedmsg/files/cert-tools}}} to be more easily peer-reviewable.

Next steps:

  • Further peer-review on the SOP. Any comments?
  • Have the keys copied into the private repo. I cannot do this myself.
  • Have puppet distribute them to hosts. I can do this.
  • Test that fedmsg picks them up correctly in stg. I can do this.
  • Migrate existing production services (tagger, relay) to use this ssl setup once its working. I can do this.

Re: Further peer-review on the SOP. Any comments?

For the crl we could expose it as we do infra-docs and other items on lockbox01.

ie, http://infrastructure.fedoraproject.org/infra/docs/
Just have http://infrastructure.fedoraproject.org/infra/fedmsg/crl.txt ?

Or, perhaps better, could we just push the crl out via puppet? (That would mean it's in the private repo, even tho it's not really private, but could allow each host to look at a local file).

Might be beyond the scope of this doc, but is there any info on how fedmsg uses the certs?
ie, each message is signed by the cert, under what cases would we reject/error on a message?

Otherwise looks pretty good to me.

Replying to [comment:7 kevin]:

Or, perhaps better, could we just push the crl out via puppet? (That would mean it's in the private repo, even tho it's not really private, but could allow each host to look at a local file).

I like this option better, that way the crl, ca.crt, and all the keys are kept in the same place, i.e., the same dir in the private repo. Easier to regenerate/maintain in my opinion. I just need to make that one file available via puppet at, let's say, http://fedoraproject.org/fedmsg/crl.pem ?

Might be beyond the scope of this doc, but is there any info on how fedmsg uses the certs?
ie, each message is signed by the cert, under what cases would we reject/error on a message?

How about I include a link to the still-in-progress fedmsg docs from the SOP instead?

Otherwise looks pretty good to me.

Cool. Let's wait a day for any other reviewers and then can I get a hand copying those keys into the private repo?

ok. I have copied the keys into the private repo.

Feel free to reopen if there's further action to take here.

Login to comment on this ticket.

Metadata