Uploaded image for project: 'OpenShift Console'
  1. OpenShift Console
  2. CONSOLE-4273

OCP 4.18 - Content Security Policy implementation

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • openshift-4.18
    • None
    • None
    • None
    • OCP 4.18 - Content Security Policy implementation
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 70% To Do, 20% In Progress, 10% Done

      Motivation:

      Content-Security-Policy (CSP) header provides a defense-in-depth measure in client-side security, as a second layer of protection against Cross-site Scripting (XSS) and clickjacking attacks.

      It is not yet implemented in the OpenShift web console, however, there are some other related security headers present in the OpenShift console that cover some aspects of CSP functionality:

      • X-Frame-Options: When set to DENY, this disallows allow attempts to iframe site (related CSP directive: `frame-ancestors`)
      • X-XSS-Protection: Protects against reflected XSS attacks in Chrome and Internet Explorer (related CSP directive: `unsafe-inline`)
      • X-Content-Type-Options: Protects against loading of external scripts and stylesheets unless the server indicates the correct MIME type, which can lead to some types of XSS attacks.

      Epic Goal

      • Implement CSP in a two phases
        • 1. Report only, in which the console will report the violations to the user and to the telemetry, so developers can have a better idea what type of violations are appearing.
          • This phase should ideally take place during several releases, at least two during which, data about the appeared violations would be gathered through telemetry. This will get plugin creators time to adapt to the change.
          • During this phase an API needs to be added to the ConsolePlugin CRD, to give plugin creators option how to provide list of their content sources, which console will register and take into account.
          • Also Console itself should remove any CSP violations which is causing.
        • 2. Enforcing, in which console will start enforcing the CSP, which will prevent plugins from loading assets from non-registered sources.

      Why is this important?

      • Add additional security level to console

      Acceptance Criteria

      • Implement 1 phase of the CSP
        • report only mode
        • surface the violations to the user
        • extend the ConsolePlugins API to give plugin creators a option how to extend plugin's source
        • extend CI to catch any CSP violations
        • update README and announce this feature so developers are aware of it

      Open questions::

      1. TBD

      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>

            vszocs@redhat.com Vojtech Szocs
            jhadvig@redhat.com Jakub Hadvig
            YaDan Pei YaDan Pei
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: