Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-765

User permissions model in Science Platform services

    XMLWordPrintable

Details

    • RFC
    • Status: Implemented
    • Resolution: Done
    • DM
    • None

    Description

      This RFC is largely informational to document a change in technical direction from a previously discussed plan. Unless you are developing Science Platform and adjacent services, it will not affect you.

      Historically the idea was that the Science Platform layer would rely on underlying infrastructure permissions. For a number of reasons, some technical and some not, we are now proceeding with a model where the service layer is responsible for authentication and the infrastructure is agnostic of the user management model. While the previous approach had the virtue of simplicity, the new approach means that:

      1. Certain service architectures (eg remote Butler) become possible
      2. Generating large number of fake accounts for scale testing becomes easy
      3. Onboarding/offboarding and other user management on a large number of heterogenous deployments (LDF, IDF, USDF, Summit, iDACs, etc) is simpler
      4. Users do not need infrastructure accounts (from the provider), just Science Platform accounts which means that scientists of all nationalities may use our services even if they are hosted in a government lab (eg SLAC)
      5. Concerns than this model would place an unsupportable burden on the A&A service have been allayed by our new service, gafaelfawr
      6. Interoperability with off-the-shelf OAuth2 services becomes easier
      7. Object Stores can be transparently substituted in services that previously relied on POSIX filesystems

      This model is already applied on Science Platform services (for example, users do not need Google accounts to use the platform deployed on IDF). We have not yet worked out the details of access to the user database tables, but have no reason to believe this approach won't work.

      Tagging all relevant parties, hopefully not a surprise to anyone at this point.

      Attachments

        Issue Links

          Activity

            ktl Kian-Tat Lim added a comment -

            My expectation has been:

            • Users write to the same POSIX-filesystem-appearing space as their Notebook Aspect home directory, their Notebook Aspect shared project space, and their Notebook Aspect scratch space. This could be provided via an actual POSIX filesystem, VOSpace, WebDAV, or something else.
            • They can execute any code they like compatible with the CPU architecture available. Executables would either be shared with batch nodes via shared filesystem or, preferably, copied to batch nodes. Those executables should ideally be containerized.
            • If there's a compelling reason (including better user experience), we could require that users submit to an instance of the workflow service used for DRP (although quite likely not the same instance) rather than submit directly to the underlying batch service. But we cannot insist on Gen3 pipelines and BPS unless we can provide a generic PipelineTask that invokes a file-based executable or script, and even then the boilerplate overhead may be prohibitive.
            ktl Kian-Tat Lim added a comment - My expectation has been: Users write to the same POSIX-filesystem-appearing space as their Notebook Aspect home directory, their Notebook Aspect shared project space, and their Notebook Aspect scratch space. This could be provided via an actual POSIX filesystem, VOSpace, WebDAV, or something else. They can execute any code they like compatible with the CPU architecture available. Executables would either be shared with batch nodes via shared filesystem or, preferably, copied to batch nodes. Those executables should ideally be containerized. If there's a compelling reason (including better user experience), we could require that users submit to an instance of the workflow service used for DRP (although quite likely not the same instance) rather than submit directly to the underlying batch service. But we cannot insist on Gen3 pipelines and BPS unless we can provide a generic PipelineTask that invokes a file-based executable or script, and even then the boilerplate overhead may be prohibitive.

            I am a tad concerned that this RFC discussion is now revolving around a poorly defined service to which we don't have a prototype, a conceptual design, or a rich set of requirements. There are a lot of ways to service requirements for user ad-hoc analytics; some of them can be serviced science-platform side, some can be serviced factory-batch side, and I would be fairly stunned if access to the latter was not gatekeeped in some way that if the as-yet non-existent user-factory-batch system required infrastructure accounts it would not be a problem.

            I'd like to bring this RFC to a close by constraining it to the Science Platform. The only Science Platform requirement relating to user batch is that nublado provide shell access to the user batch system.

            frossie Frossie Economou added a comment - I am a tad concerned that this RFC discussion is now revolving around a poorly defined service to which we don't have a prototype, a conceptual design, or a rich set of requirements. There are a lot of ways to service requirements for user ad-hoc analytics; some of them can be serviced science-platform side, some can be serviced factory-batch side, and I would be fairly stunned if access to the latter was not gatekeeped in some way that if the as-yet non-existent user-factory-batch system required infrastructure accounts it would not be a problem. I'd like to bring this RFC to a close by constraining it to the Science Platform. The only Science Platform requirement relating to user batch is that nublado provide shell access to the user batch system.

            I think you are saying two things: "we believe that user-provided batch code execution is not part of the RSP, besides shell access" (and indeed it was anticipated that project DACs would use an underlying infrastructure component provided by the facility) and "we have not yet worked out the details of user-provided batch code execution, but have reason to believe that either this approach (accounts in the RSP service layer) will work or else underlying infrastructure accounts can be provided to such users for authentication, authorization, and resource management."  Is that correct?

            ktl Kian-Tat Lim added a comment - I think you are saying two things: "we believe that user-provided batch code execution is not part of the RSP, besides shell access" (and indeed it was anticipated that project DACs would use an underlying infrastructure component provided by the facility) and "we have not yet worked out the details of user-provided batch code execution, but have reason to believe that either this approach (accounts in the RSP service layer) will work or else underlying infrastructure accounts can be provided to such users for authentication, authorization, and resource management."  Is that correct?

            I agree with Frossie. Let's handle user batch separately - but soon, so that USDF can make a plan.

            gpdf Gregory Dubois-Felsmann added a comment - I agree with Frossie. Let's handle user batch separately - but soon, so that USDF can make a plan.

            Adopting this in the narrow intended way of Science Platform services, excluding user batch.

            frossie Frossie Economou added a comment - Adopting this in the narrow intended way of Science Platform services, excluding user batch.

            People

              frossie Frossie Economou
              frossie Frossie Economou
              Adam Thornton, Christine Banek, Colin Slater, Dominique Boutigny, Fabio Hernandez, Fritz Mueller, Frossie Economou, Gregory Dubois-Felsmann, Hsin-Fang Chiang, Jim Bosch, Kian-Tat Lim, Richard Dubois, Russ Allbery, Simon Krughoff (Inactive), Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                Jenkins

                  No builds found.