-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
OCP 4.18 - Content Security Policy implementation
-
False
-
None
-
False
-
Not Selected
-
To Do
-
8% To Do, 15% In Progress, 77% 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.
- 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.
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::
- 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>