alexlovelltroy
commented
7 months ago I may be reaching here, but if the site needs to manage an external list of these resources, would it be desirable to maintain it in one place rather than two? If the site exposes a dns zone that the cluster can get through XRF, could we use that as our allow-list with a default deny rule?
Users running on HPC systems require access to a finite set of internal and external resources in order to do their work. A common workflow is to allow more lax network access control on front end resources, and more strict network access control on compute node (back end) resources. This is a familiar pattern that would benefit from formal treatment in the OpenCHAMI system. Current practice is to try a server request, see if it works, and then email a team to amend the policy as needed.
Describe the solution you'd like A single allow/deny list for each access type: internal and external. Each list would consist of DNS entries and a valid DNS lookup authority. These lists will apply to a single system and may be inherited by multiple systems. A central configuration point will ensure network rules are applied consistently and with minimal config duplication. A user-facing CLI interface to inspect these policies and request new exceptions would expedite user workflows that require new allow exceptions, or new exceptions to deny bad DNS entries per internal security policies.
Describe alternatives you've considered A CLI to view the current policies would be useful by itself. A CLI to request new exceptions may be a convenience with implementation complexity that is not worth the benefit.