Flux-core: Auto-generating keys for first-time users?

[SteVwonder]

Rather than printing an error message and bailing out, is it worth auto-generating keys when flux start is run for users without a ~/.flux directory? It would eliminate an initial, seemingly artificial hurdle for new users.

I assume one downside would be there are security implications (I know too little to enumerate them), but I wonder if there are technological solutions to those that would avoid new users from having to manually run flux keygen after a failed attempt at flux start. For example, maybe an option to flux start or an instance configuration option that overrides this autogen behaviour (which we can set in high-security environments or for the system instance).

I believe @garlick and I already had a similar discussion to this last week. Sorry for any deja-vu, but my feeble brain has already forgotten the discussion/answer. Figured it would at least be good to record the answer in a searchable/indexed location.

[garlick]

I'm not sure I see a reason not to generate the keys automatically.

It might be a bit racy to do during instance start up. There would need to be synchronization so that only one rank creates the keys, and then they would need to be instantly available on other ranks.

[garlick]

I'm remembering an old idea: have each broker generate a unique, private keypair internally. Then share the public keys with PMI. I think "server" end of each socket needs (public, private) but "client" end only needs (public). No key file?

[grondo]

It might be a bit racy to do during instance start up. There would need to be synchronization so that only one rank creates the keys, and then they would need to be instantly available on other ranks.

Not only racy at startup, but racy between startup of multiple instances. (Imagine first-time user of flux submits many jobs to system RM, and they all start at the same time..)

have each broker generate a unique, private keypair internally. Then share the public keys with PMI.

Would this prevent an instance from growing at a later time? If not and any old broker can connect to an existing instance and share its public key, how is this secure? (Somehow the origin needs to be traced back to something the user owns.) Munge credential?

[garlick]

Hmm, good points.

Our PMI implementation is "secure" in that it uses fd passing to only hand off access to the PMI KVS to the intended recipients. Growing might need a different mechanism to share keys and broker endpoint URI's? Or it could offer the pre-populated PMI KVS to the new brokers. More thought required...

BTW I think you got the whole picture @grondo, but I was overly brief in my comment above and not very clear in my language. So let me try to clarify for the record what I was thinking:

For zeromq CURVE security, in addition to its own keys, a client needs the public key of the server and a server needs a list of public keys of authorized clients. Each broker can be client and/or server (client to upstream TBON peer, server to downstream peers).

I was picturing

1. each broker generates its own (public, private) keypair
2. broker puts public key into PMI KVS under its rank
3. broker gets public keys of expected TBON peers from PMI kvs by rank

I'm pretty sure we would have to rewrite the canned czmq ZAP (zeromq authentication protocol) agent for the server implementation to access the set of authorized keys from certificates in memory rather than certificates on disk. That's the main coding work, the rest is fairly simple, although there is an outdated zsecurity "class" that assumes keys on disk and would need an overhaul. Both of these things need work anyway to support GSSAPI/Kerberos V.

The security layer in zeromq does all the heavy lifting to generate session keys and provide authenticity and privacy once handed the initial keys.