= 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:
Next steps:
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]:
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 ?
How about I include a link to the still-in-progress fedmsg docs from the SOP instead?
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.