Uploaded image for project: 'Operator Runtime'
  1. Operator Runtime
  2. OPRUN-4018

OLMv0: Enforce `readOnlyRootFilesystem: true` for enhanced security (and provide brief justification for `false` exceptions)

XMLWordPrintable

    • OLMv0: Enforce `readOnlyRootFilesystem: true` for enhanced security (and provide brief justification for `false` exceptions)
    • Product / Portfolio Work
    • OCPSTRAT-1976OLMv0: Enforce `readOnlyRootFilesystem: true` for enhanced security (and provide brief justification for `false` exceptions)
    • 0% To Do, 0% In Progress, 100% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • None

      Epic Goal

      • Set `readOnlyRootFilesystem: true` in pods of `openshift-operator-lifecycle-manager` namespace. Including catalog-operator, olm-operator, package-server-manager, packageserver, and collect-profiles job.
      • For 4 default CatalogSources where `readOnlyRootFilesystem: false`, provide clear and concise explanations outlining the specific use cases and justifications :
        • certified-operators
        • community-operators
        • redhat-marketplace
        • redhat-operators

      Current OLM State

      Analysis of OLMv0 pods in OpenShift `4.20.0-0.nightly-2025-07-21-025204`:

      • Pods in the `openshift-operator-lifecycle-manager` namespace:
        • readOnlyRootFilesystem is not explicitly set in any pods
      • Pods in the `openshift-marketplace` namespace:
        • 4 out of 5 pods have `readOnlyRootFilesystem` explicitly set to `false` (catalog pods from the 4 default catalogs).
        • The marketplace-operator pod has this setting: readOnlyRootFilesystem: true
        • The false setting in the catalog pods likely reflects the need for filesystem write access

      Why is this important?

      • It improves security by ensuring that executables and configuration shipped in the signed image cannot be manipulated by attackers at runtime.

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. ...

      Open questions::

      1. ...

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              rh-ee-cchantse Catherine Chan-Tse
              rhn-support-jiazha Jian Zhang
              None
              Jian Zhang Jian Zhang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: