Future Streams Authorization (v4.5.0+)

[morrone]

We need to discuss what our authorization model should be for the ldms streams service in ldmsd in the future (the code on branch "main", which will become v4.5.0).

To have that dicsussion, it would be very helpful to have more clear, detailed documentation about what streams actually are. Some questions that should probably be answered by the documentation are:

• What are the semantics of a "stream" and "stream messages"?
• What, if any, is the resilience model for streams messages?

A system administrator using ldmsd would likely have the following questions about streams:

• How do I control who can publish messages to which streams?
• How do I control who can subscribe to messages from which streams?

[tom95858]

@morrone, can we combine this with @nichamon issue #1547

[morrone]

I intentionally kept them separate, because it has been made clear that we are not going to address these things on b4.4 for v4.4.5 (only to make it possible to entirely enable/disable streams functionality). So discussion #1547 is about whether streams are enabled by default, in the very near term, on b4.4. Whereas this discussion is about the future of streams authorization on the main branch (v4.5.x and beyond). I think combining the two discussions is going to confuse people.

[morrone]

To word things another way, @narategithub said the following:

on current main [...] bob can connect to ldmsd and publish anything on any stream. Be nice, bob!

We need to move beyond hoping users will "be nice" and actually implement authorization. We need to have a clear way for a system administrator to answer the following question, which is stated at the beginning of this conversation:

How do I control who can publish messages to which streams?

And perhaps for the system administrator to ask that question, they have to know the answer to "what are Streams in LDMSD?".

If @tom95858 are sure this is already addressed on main, then please do share the answer that we would give that sysadmin. It certainly could be that the answer just isn't documented, and I'd be happy to learn that no code development is needed to answer all the questions that I've raised in this discussion (#1548).

[tom95858]

@morrone, @narategithub has published a pull request and he is now working on the documentation. I think it will address the key questions you have brought up, but I think it will also point out some things that may be the source of our collective confusion. I think we will have the docs by tomorrow.

[morrone]

I think we have gotten onto the same page in these comments in issue #1527.

The summary is that the main branch does not currently address the key issues that I have raised. So I would suggest the following plan:

In the longer term:

• Implement streams authorization at publish time (and subscribe time) that is configurable by the sysadmin.

In the shorter term:

• Port a variant of PR Add requests to enable/disable streams communication #1543 to main.
• Make streams disabled by default on main.
• Retire the older "ldmsd streams" on main (this one suggested by @tom95858)

[morrone]

Here is first pass at a possible access control list configuration. Not that there are some details that need to be worked out, especially in how wildcards interact between rules.

access_control_list:
- uids:
  - 1001 # flux's uid
#- gids:
#  - 1001
  interfaces:
  - streams_publish
  streams:
  - flux
  permission: allow
- uids: [1001] # flux's uid
  interfaces: [streams_subscribe]
  streams: [flux_respond]
  permission: allow
- uids: [any]
  interfaces: [streams_publish, streams_subscribe]
  streams: [flux]
  permission: deny
- uids: [any]
  interfaces: [streams_publish, streams_subscribe]
  streams: ["^flux"]
  permission: allow

[nichamon]

I'm posting on behalf of @baallan as he shared an alternative. @baallan also wants to use user name besides UID as, in his environment, the same user name could have different UID on the host and in containers.

acl:
  - capability: message_subscribe:flux
     hosts: .*  ;# this is what hosts the rule is active on , not what hosts connect to it.
     permission: 
        allow:
          users: flux
        deny:
          users: all
  - capability: message_subscribe:.*
     permissions:
        allow:
           users: bob
           groups: wg-ldms-users
           producers: [hostlist or regex] ;# this is what hosts/producers can connect&pub/sub
  - capability: [sampler_instance_start_stop:papi_slow, sampler_instance_start_stop:papi_fast]
     permissions:
        allow:
           users: bob
           groups: wg-ldms-users
           producers: [hostlist or regex];# this is what hosts/producers can connect& change the sampler used

[morrone]

I don't think that differing IDs inside of containers is necessarily a good reason to do this. We would need additional cross-realm authentication to validate that "bob" in one realm (outside the container) is the same as "bob" in another realm (inside the container). Things like munge work on UID/GID, not username, and ldmsd currently works with UID/GID internally. I think it would be out of scope to teach ldmsd cross-realm username mapping.
Also, I think that the acls need to be a list rather than a mapping. Without a fixed order for the rules, figuring out the intersection and precedence of rules probably becomes pretty difficult.

[baallan]

I did intend it to be a list. I've updated the example, replacing rule[1-3] with list markers.
I do not intend that ldms get tasked with mapping uid/gid to other uid/gid across container boundaries. But within either bare metal hosted ldmsd or inside a container ldmsd, admins should be able to name, not number, users in their security rules/roles.

[baallan]

Within my local systems, usernames are consistent across 'supported' container boundaries. UIDs inside containers are also kept consistent across 'supported' container instances by site policy. There is a fixed uid/subuid relationship that has been implemented somehow.

[morrone]

Linux allows setting up uid mapping, but that doesn't mean that the usernames are mapped correctly. That would require, at a minimum, also mapping /etc/passwd into the container's space as well. I'm not entirely sure how enforceable that sort of mapping would be.

I suppose if people recognize it might not be a safe thing to do, I'm not necessarily opposed to implementing the getpwnam_r() call.