Merge branch 'latest' into develop

source/customizations.rst

@@ -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

source/index.rst

@@ -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

source/security.rst

@@ -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

source/security/vulnerability-management.rst

@@ -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.