Plan to support GEOAxIS, OpenID, OAuth2, Kerberos authentication, SELinux Multi Level Security (MLS) and Multi Category Security (MCS)

[wrthissell]

Dear flux-security Developers,
I am studying your flux-framework capability for suitability for our application ecosystem. Our ecosystem has Information Assurance (IA) requirements for GEOAxIS, OpenID, OAuth2, Kerberos authentication, SELinux Multi Level Security (MLS) and Multi Category Security (MCS) integration, partially described in:

https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf

and

https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf .

  I have noticed that your framework is currently only supporting:

https://github.com/dun/munge/

That framework does not meet our IA requirements.
Here are some links for GEOAxIS, OpenID, OAuth2, Kerberos authentication, SELinux Multi Level Security (MLS) and Multi Category Security (MCS):

https://portal.gxaws.com/
https://openid.net/
https://github.com/openid
https://oauth.net/2/
https://github.com/golang/oauth2
https://web.mit.edu/kerberos/
https://github.com/krb5
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/using-multi-level-security-mls_using-selinux
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/assembly_using-multi-category-security-mcs-for-data-confidentiality_using-selinux

 Is integrating these capabilities part of your current development roadmap, and if so, where may I find this documented?  If not, when do you estimate that these capability integrations will be integrated into your development roadmap and when do you estimate that they will be integrated?
  
 Thank you in advance for your reply.

Sincerely yours,

wrthissell

[garlick]

Hi - apologies for the delay responding

Please note that network access to Flux by users is via ssh, which means that all security mechanisms supported by ssh may be employed including kerberos, oauth, etc..

Flux internally builds an overlay network to connect its distributed components. The overlay network uses zeromq and so its security mechanisms are available to Flux, although currently Flux only allows the CURVE mechanism to be selected. In the past we have tested with kerberos with the idea that the system level flux might use kerberos, while "subinstances" (batch jobs and so forth) would continue to use CURVE. Implementing that capability is tractable, but at the moment we have other priorities and there has not been a demand for it.

MUNGE is only used to sign job requests, part of a defense in depth strategy. Only the system level Flux is permitted to launch jobs as other users so we could trust that it can deliver the job requests to the IMP (the which handles the user transition) unaltered. However, we have the IMP check the signature anyway in case the unprivileged flux user was somehow compromised.

For further clarification on the overall Flux security situation, you may find this brief Flux security overview useful. It contains references to documents containing further detail.

[garlick]

I should have mentioned that if you do not intend to deploy Flux as the native resource manager on a cluster, e.g. launching Flux as a job under another resource manager like slurm or LSF, then the security picture is far simpler. In that case, all the Flux components would run as the end user and only that user is allowed to access it and run jobs within. That user's job requests are not signed, and the IMP is not used. The overlay network is still secured with CURVE but an on-disk certificate is not used; instead, each Flux broker generates a CURVE cerificate in memory and uses PMI (the standard process management interface offered by many resource managers) to exchange public keys.

[garlick]

You also mention SELinux. I have a limited understanding of the details, but others at LLNL are interested in building up a software ecosystem that would enable compute and storage resources to be securely shared among classes of users that we would normally keep separate. As I understand it, the tie-in with Flux would be to capture an SELInux context in a user's job request and have the IMP re-establish it when it executes the job. Since jobs are already signed by MUNGE, dun/munge#70 would take care of the "front half" of this.

We don't have a design for this on record yet for Flux and no timeline at this point. See also #95.

[wrthissell]

Dear Jim,
Thank you for your detailed reply. I shall study your comments and get back to you with additional questions and comments.

Sincerely yours,

wrthissell

[wrthissell]

Dear Jim,
Here is a link with some links that describe how MLS and MCS is implemented in RHEL, using SELinux and by extension to Centos, Rocky, and Alma Linux.:

https://daos.groups.io/g/daos/topic/96623103?p=Created,,,20,1,0,0

I understand PBSPro implemented MLS and MCS using SELinux back in 2015. It is on my todo list to research other job schedulers integration with MLS and MCS using SELinux with Kerberos authentication.

Sincerely yours,

wrthissell