search

Cray-HPE / community

MIT License
5 stars 1 forks source link

Security Enhancements To HMNFD Subscription API #31

Closed mpkelly-hpe closed 2 years ago

mpkelly-hpe commented 2 years ago

Abstract

HMNFD's subscription API is not secure. Enhancements need to be made in order to do proper OPA filtering.

Problem Statement

Currently, agents that wish to subscribe for State Change Notifications (SCNs) do so using HMNFD's /subscribe API. The information pertinent to the subscription, as well as the identity of the subscriber, is currently inside of the JSON payload sent to POST, PATCH, and DELETE API endpoints.

This makes OPA filtering difficult, since it has to parse the JSON payload in order to do any sort of filtering.

Agents (such as ORCA) subscribe for SCNs using the /subscribe API. Since it is not currently filtered, bad actors could use this API for DOS type attacks by overwhelming HMNFD with lots of bogus subscriptions. OPA filtering must be efficient to be effective.

Internal References

HMNFD swagger: https://github.com/Cray-HPE/hms-hmi-nfd/blob/master/api/swagger.yaml

External References

N/A

Proposed Solution(s)

The HMS team intends to enhance the HMNFD API to include XName information in the subscription URLs in order to facilitate very efficient OPA filtering.

The new API set would deprecate the following:

POST /hmi/v1/subscribe
PATCH /hmi/v1/subscribe
DELETE /hmi/v1/subscribe

and add the following:

# Create  a new subscription or replace an existing one
PUT /hmi/v2/subscriptions/{xname}/agents/{agent}

# Delete all subscriptions on a given node
DELETE /hmi/v2/subscriptions/{xname}/agents

# Delete a specific subscription on a given node
DELETE /hmi/v2/subscriptions/{xname}/agents/{agent}

Note that the existing subscriptions API will carry over to the v2 API (as will all other API endpoints not relevant to this document):

# Fetch subscription information
GET /hmi/v1/subscriptions

Note that this will require that the HMNFD API be implemented as a v2 API, requiring the deprecation of the v1 API.

Impact of Action/Inaction

If we don't implement this V2 API, we will leave HMNFD open to the DOS-like vulnerability described above.

It is possible to do payload-based filtering in OPA but there are performance issues with that, and it may be that large payloads (which are expected on large systems) could bog OPA down even more or even fail.

Further Information

This EP will need to go to the Solution Interoperability Team. https://github.com/Cray-HPE/community/wiki/Enhancement-Proposals#solution-interoperability-team-sit-engagement_

Suggested Reviewers

Specifically:

And, the tech-leads team members.

Comment Period

Comment period for this proposal shall close on Nov 5, 2021.

nieuwsma commented 2 years ago

I approve.

rfrost-hpe commented 2 years ago

This is being handled by https://connect.us.cray.com/jira/browse/CASMHMS-5231 and https://connect.us.cray.com/jira/browse/CASMHMS-5230