Skip to content

Commit

Permalink
add basic security pages (#985)
Browse files Browse the repository at this point in the history
* add basic security pages

* Update security.rst

* Update security.rst

* Update index.rst

* updated spacing in customization.rst so \'rake build\' works
  • Loading branch information
matt257 authored Jul 16, 2024
1 parent c6021fd commit 669ff87
Show file tree
Hide file tree
Showing 4 changed files with 133 additions and 40 deletions.
78 changes: 39 additions & 39 deletions source/customizations.rst
Original file line number Diff line number Diff line change
Expand Up @@ -281,53 +281,53 @@ The following example adds all directories within the specified base directories


.. code-block:: ruby
# /etc/ood/config/apps/dashboard/initializers/ood.rb

Rails.application.config.after_initialize do
OodFilesApp.candidate_favorite_paths.tap do |paths|

# Hash of base paths to check for additional directories with titles
# location => Title
base_paths = {
'/home/share/' => 'Shared home',
'/srv/scratch/shares/' => 'Shared scratch',
'/srv/scratch/groups/' => 'Group scratch',
'/srv/fast/users/' => 'Fast user'
# Add more paths and titles here if needed
}

base_paths.each do |base_path, title|

# Check if the base path exists and is a directory, to avoid error
next unless Dir.exist?(base_path)
# Get all entries in the current base path
Dir.entries(base_path).each do |entry|
# Construct the full path for the current entry
full_path = File.join(base_path, entry)

# Skip if it's not a directory or if it's a special entry like '.' or '..'
next unless File.directory?(full_path) && !['.', '..'].include?(entry)

# Check if the directory is readable and executable
if File.readable?(full_path) && File.executable?(full_path)
# Access the value of the current base_path using the `title` variable
paths << FavoritePath.new(full_path, title: "#{title}: #{File.basename(full_path)}")
# /etc/ood/config/apps/dashboard/initializers/ood.rb
Rails.application.config.after_initialize do
OodFilesApp.candidate_favorite_paths.tap do |paths|
# Hash of base paths to check for additional directories with titles
# location => Title
base_paths = {
'/home/share/' => 'Shared home',
'/srv/scratch/shares/' => 'Shared scratch',
'/srv/scratch/groups/' => 'Group scratch',
'/srv/fast/users/' => 'Fast user'
# Add more paths and titles here if needed
}
base_paths.each do |base_path, title|
# Check if the base path exists and is a directory, to avoid error
next unless Dir.exist?(base_path)
# Get all entries in the current base path
Dir.entries(base_path).each do |entry|
# Construct the full path for the current entry
full_path = File.join(base_path, entry)
# Skip if it's not a directory or if it's a special entry like '.' or '..'
next unless File.directory?(full_path) && !['.', '..'].include?(entry)
# Check if the directory is readable and executable
if File.readable?(full_path) && File.executable?(full_path)
# Access the value of the current base_path using the `title` variable
paths << FavoritePath.new(full_path, title: "#{title}: #{File.basename(full_path)}")
end
end
end
end
end
end
end
- The variable ``base_paths`` is an hash (``dirname`` => ``Title``) of all directories you want to parse. For the directory ``OSC_test`` in ``/srv/scratch/groups/``; the favorite path will be display as following
# The variable ``base_paths`` is an hash (``dirname`` => ``Title``) of all directories you want to parse. For the directory ``OSC_test`` in ``/srv/scratch/groups/``; the favorite path will be displayed as following
|Group scratch OSC_test: /srv/scratch/groups/OSC_test
| Group scratch: OSC_test | /srv/scratch/groups/OSC_test |
On each request, the Dashboard will check for the existence of the directories
in ``OodFilesApp.candidate_favorite_paths`` array and whichever directories
exist and the user has access to will appear as links in the Files menu under
the Home Directory link.
On each request, the Dashboard will check for the existence of the directories
in ``OodFilesApp.candidate_favorite_paths`` array and whichever directories
exist and the user has access to will appear as links in the Files menu under
the Home Directory link.
.. figure:: /images/files_menu_shortcuts_osc.png
:align: center
Expand Down
3 changes: 2 additions & 1 deletion source/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -81,9 +81,10 @@ These are institutions who were early adopters or provided HPC resources for dev

architecture
reference
security
release-notes
version-policy
glossary
glossary

.. _website: https://openondemand.org/
.. _bowdoin: https://www.bowdoin.edu/it/resources/high-performance-computing.html
Expand Down
50 changes: 50 additions & 0 deletions source/security.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
.. _security:

Security
========

Introduction
------------
This document details the security framework for Open OnDemand, providing essential information that administrators need to know for secure deployment and operation.

Considerations
--------------
This section outlines key security advantages and areas for vigilance within the Open OnDemand environment.

Advantages
^^^^^^^^^^

- **Per-user Nginx (PUN) Architecture**: By running individual Nginx instances per user, Open OnDemand ensures that actions such as file access are conducted under user-specific non-root privileges, which isolates processes and enhances security.

- **Robust Authentication**: Open OnDemand supports various authentication methods. It particularly emphasizes secure protocols over less secure options like Basic or LDAP authentication, reinforcing its commitment to high security standards.

Limitations
^^^^^^^^^^^

- **HTTP Traffic to Origin Servers**: Traffic to backend services, including computational resources like Jupyter servers, is currently over HTTP, which is unencrypted. Plans are underway to upgrade this to HTTPS to ensure encryption of data in transit, thereby bolstering security.

Security Controls
-----------------

- **Monitoring and Logging**: Comprehensive logging mechanisms are integral for security audits and incident response. Detailed guidelines and settings for these features can be found at :ref:`logging`.

- **Vulnerability Management**: Active management of security weaknesses includes regular updates and patches. Detailed processes and current security advisories are available at :ref:`vulnerability-management`.

- **Security Audits**: The platform undergoes periodic security audits by Trusted CI, the NSF Cybersecurity Center of Excellence. Summaries of these audits are available, with the latest report accessible `here <https://openondemand.org/sites/default/files/documents/Trusted%20CI%20Open%20OnDemand%20Engagement%20Final%20Report%20-%20REDACTED%20FOR%20PUBLIC%20RELEASE%20210712_0.pdf>`_.

Conclusion
----------
Maintaining a secure and robust operational environment is critical for the success of Open OnDemand. Administrators are encouraged to implement the security practices recommended in this guide and to regularly review security settings and updates.


Relevant References
-------------------

.. toctree::
:maxdepth: 2
:caption: Security Topics

security/vulnerability-management
authentication/overview
how-tos/monitoring/logging
customizations
42 changes: 42 additions & 0 deletions source/security/vulnerability-management.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
.. _vulnerability-management:

Vulnerability Management
========================

Introduction
------------

Vulnerability management is a critical component of the security strategy for Open OnDemand. This document outlines the procedures for reporting and managing vulnerabilities.

Reporting a Vulnerability
-------------------------

If you have security concerns or think you have found a vulnerability, please submit a private report by visiting the 'Security' section of our GitHub located at `GitHub Open OnDemand Security <https://github.com/OSC/ondemand/security/>`_ and clicking 'Report a vulnerability'.

For direct inquiries or issues in submitting a report, contact the core project team via email at [email protected].

Disclosure Policy
-----------------

- Upon reporting, you will receive a response within hours, acknowledging the receipt of the report.
- A primary handler from the team will be assigned to coordinate the fix and release process:
- Confirm the problem and determine the affected versions (1-2 days).
- Audit code to find any potential similar problems.
- Prepare fixes for all releases still under maintenance and release as soon as possible.

Comments on Policy
------------------

Suggestions to improve this process can be made via submitting a ticket, opening a Discourse topic, or a pull request.

Security Audits
---------------

Open OnDemand has been audited several times by Trusted CI, the NSF Cybersecurity Center of Excellence. The latest engagement report is available `here <https://openondemand.org/sites/default/files/documents/Trusted%20CI%20Open%20OnDemand%20Engagement%20Final%20Report%20-%20REDACTED%20FOR%20PUBLIC%20RELEASE%20210712_0.pdf>`__. These audits have helped shape the security landscape of the platform and contribute to its ongoing security enhancements.

Conclusion
----------

Effective vulnerability management is crucial for maintaining the security and integrity of Open OnDemand. Users and contributors play a vital role in this process by reporting potential security vulnerabilities through GitHub, ensuring the platform's continued safety.

.. note:: For details on the specific vulnerability management steps, please see the GitHub repository guidelines or the security policies linked above.

0 comments on commit 669ff87

Please sign in to comment.