FYI, I made a pull request containing the basic strategy for TLS in confluent that I expect to be the facility across the board. https://github.com/xcat2/confluent/pull/54
There's two policy on 'new' keys, automatic or manual. If the policy is 'automatic' (the default) then a new target will have it's certificate fingerprint stored and continue. If 'manual', it will error on any request that doesn't have either a CA or a pre-declared key in the attribute. If there is a mismatch, it wil error out with error data that could be used to correct the setting. If pressed I could add an 'ignore' policy to completely not verify certificate, effectively ignoring the upsides of TLS entirely. So basically, a 'ssh' like approach to key handling, which I think is a better match for the typical internal network. For now, not supporting CA (due to some complications in the way python's tls module works, hard to do both a traditional CA verification and have room for a fallback). I figure this is a good compromise between having a managed x509 infrastructure and just ignoring it completely. Hopefully will do the work to make it easy for modules to support a trusted CA. Just wondering if this design strikes people as reasonable. Note similar things will happen with ssh keys, though without the CA portion, and even then really only there for web enablement, not expected to be used from commandline.
------------------------------------------------------------------------------
_______________________________________________ xCAT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xcat-user
