From 74ca88c4978f719854f34d840c1ef91e053eeb10 Mon Sep 17 00:00:00 2001 From: matt257 Date: Tue, 16 Jul 2024 09:36:37 -0400 Subject: [PATCH 1/5] add basic security pages --- source/index.rst | 2 + source/security.rst | 48 ++++++++++++++++++++ source/security/vulnerability-management.rst | 42 +++++++++++++++++ 3 files changed, 92 insertions(+) create mode 100644 source/security.rst create mode 100644 source/security/vulnerability-management.rst diff --git a/source/index.rst b/source/index.rst index cb76b64b..56137b8b 100644 --- a/source/index.rst +++ b/source/index.rst @@ -81,10 +81,12 @@ These are institutions who were early adopters or provided HPC resources for dev architecture reference + security release-notes version-policy glossary issues/overview + .. _website: https://openondemand.org/ .. _bowdoin: https://www.bowdoin.edu/it/resources/high-performance-computing.html diff --git a/source/security.rst b/source/security.rst new file mode 100644 index 00000000..feb74a8e --- /dev/null +++ b/source/security.rst @@ -0,0 +1,48 @@ +.. _security: + +Security +================= + +Introduction +------------ + +This document provides an overview of the security framework implemented in Open OnDemand, focusing on practical security concerns administrators need to consider when installing and managing the platform. + +Security Concerns +----------------- + +**The Good:** + +- **PUN Architecture**: The Per-user Nginx (PUN) architecture underpins the security model where web servers, run by individual users rather than the root, handle user requests. This ensures that all actions, including file accesses, are executed under non-root user privileges, enhancing security by isolating user processes. + +- **Apache Authentication**: Authentication is mandatory, with the type of scheme being adjustable per site. Open OnDemand discourages and does not document insecure basic authentication mechanisms such as Basic or LDAP to promote stronger security measures. + +**The Bad:** + +- **HTTP Traffic to Origin Servers**: Currently, traffic to origin servers (like compute nodes running applications such as Jupyter) is handled via HTTP. This presents a risk as it is not encrypted. Efforts are ongoing to shift this traffic to HTTPS to secure all data in transit. + +Security Features +----------------- + +- **Monitoring and Logging**: Extensive monitoring and logging are in place, providing crucial tools for security auditing and incident response. For more information, see :ref:`logging`. + +- **Vulnerability Management**: Vulnerabilities within Open OnDemand are diligently identified, reported, and managed. For more details on this process, see :ref:`vulnerability-management`. + +- **Security Audits**: Open OnDemand has undergone several security audits by Trusted CI, the NSF Cybersecurity Center of Excellence. The latest audit report is available `here `__. + +Conclusion +---------- + +Maintaining robust security is pivotal for the operation of Open OnDemand. Ongoing efforts are dedicated to strengthening the security measures in place. Users and administrators are encouraged to adhere to the outlined best practices and security guidelines to ensure a secure operational environment. + +Relevant References +------------------- + +.. toctree:: + :maxdepth: 2 + :caption: Security Topics + + security/vulnerability-management + authentication/overview + how-tos/monitoring/logging + customizations diff --git a/source/security/vulnerability-management.rst b/source/security/vulnerability-management.rst new file mode 100644 index 00000000..b23168de --- /dev/null +++ b/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 `_ and clicking 'Report a vulnerability'. + +For direct inquiries or issues in submitting a report, contact the core project team via email at security@openondemand.org. + +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 `__. 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. From b79b0bd06dae71e27ebd51f051e993baa3a49c6f Mon Sep 17 00:00:00 2001 From: matt <57604545+matt257@users.noreply.github.com> Date: Tue, 16 Jul 2024 10:11:29 -0400 Subject: [PATCH 2/5] Update security.rst --- source/security.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/security.rst b/source/security.rst index feb74a8e..88e5d802 100644 --- a/source/security.rst +++ b/source/security.rst @@ -8,8 +8,8 @@ Introduction This document provides an overview of the security framework implemented in Open OnDemand, focusing on practical security concerns administrators need to consider when installing and managing the platform. -Security Concerns ------------------ +Considerations +-------------- **The Good:** From 3c6ccdd781fc05c186e304c1489655077a850af6 Mon Sep 17 00:00:00 2001 From: matt <57604545+matt257@users.noreply.github.com> Date: Tue, 16 Jul 2024 11:34:21 -0400 Subject: [PATCH 3/5] Update security.rst --- source/security.rst | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/source/security.rst b/source/security.rst index 88e5d802..99f1a07c 100644 --- a/source/security.rst +++ b/source/security.rst @@ -1,39 +1,44 @@ .. _security: -Security +Security Overview ================= Introduction ------------ - -This document provides an overview of the security framework implemented in Open OnDemand, focusing on practical security concerns administrators need to consider when installing and managing the platform. +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. -**The Good:** +Advantages +^^^^^^^^^^ -- **PUN Architecture**: The Per-user Nginx (PUN) architecture underpins the security model where web servers, run by individual users rather than the root, handle user requests. This ensures that all actions, including file accesses, are executed under non-root user privileges, enhancing security by isolating user processes. +- **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. -- **Apache Authentication**: Authentication is mandatory, with the type of scheme being adjustable per site. Open OnDemand discourages and does not document insecure basic authentication mechanisms such as Basic or LDAP to promote stronger security measures. +- **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. -**The Bad:** +Limitations +^^^^^^^^^^^ -- **HTTP Traffic to Origin Servers**: Currently, traffic to origin servers (like compute nodes running applications such as Jupyter) is handled via HTTP. This presents a risk as it is not encrypted. Efforts are ongoing to shift this traffic to HTTPS to secure all data in transit. +- **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 Features +Security Controls ----------------- +Open OnDemand allows customization of security features to fit different operational environments: + +- **File Browsing Restrictions**: Administrators can configure file access restrictions to prevent users from browsing sensitive parts of the file system. This is managed through an allowlist, or it can be disabled entirely. For more information, see :ref:`file-access-controls`. -- **Monitoring and Logging**: Extensive monitoring and logging are in place, providing crucial tools for security auditing and incident response. For more information, see :ref:`logging`. +- **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**: Vulnerabilities within Open OnDemand are diligently identified, reported, and managed. For more details on this process, see :ref:`vulnerability-management`. +- **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**: Open OnDemand has undergone several security audits by Trusted CI, the NSF Cybersecurity Center of Excellence. The latest audit report is available `here `__. +- **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 `_. 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. -Maintaining robust security is pivotal for the operation of Open OnDemand. Ongoing efforts are dedicated to strengthening the security measures in place. Users and administrators are encouraged to adhere to the outlined best practices and security guidelines to ensure a secure operational environment. Relevant References ------------------- From 7cc343214506dbb754faa6fc7f90fc6d2b64d68e Mon Sep 17 00:00:00 2001 From: matt <57604545+matt257@users.noreply.github.com> Date: Tue, 16 Jul 2024 13:41:38 -0400 Subject: [PATCH 4/5] Update index.rst --- source/index.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/source/index.rst b/source/index.rst index 91e8fe80..4c62a6c7 100644 --- a/source/index.rst +++ b/source/index.rst @@ -84,9 +84,7 @@ These are institutions who were early adopters or provided HPC resources for dev security release-notes version-policy - glossary - issues/overview - + glossary .. _website: https://openondemand.org/ .. _bowdoin: https://www.bowdoin.edu/it/resources/high-performance-computing.html From f273db94d1c888775e30a6c2b720fdfb72ff56b3 Mon Sep 17 00:00:00 2001 From: matt257 Date: Tue, 16 Jul 2024 14:07:27 -0400 Subject: [PATCH 5/5] updated spacing in customization.rst so \'rake build\' works --- source/customizations.rst | 78 +++++++++++++++++++-------------------- source/security.rst | 7 +--- 2 files changed, 41 insertions(+), 44 deletions(-) diff --git a/source/customizations.rst b/source/customizations.rst index bd11f9e6..13f2b832 100644 --- a/source/customizations.rst +++ b/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 diff --git a/source/security.rst b/source/security.rst index 99f1a07c..a8bce0d6 100644 --- a/source/security.rst +++ b/source/security.rst @@ -1,7 +1,7 @@ .. _security: -Security Overview -================= +Security +======== Introduction ------------ @@ -25,9 +25,6 @@ Limitations Security Controls ----------------- -Open OnDemand allows customization of security features to fit different operational environments: - -- **File Browsing Restrictions**: Administrators can configure file access restrictions to prevent users from browsing sensitive parts of the file system. This is managed through an allowlist, or it can be disabled entirely. For more information, see :ref:`file-access-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`.