-
Bug
-
Resolution: Done-Errata
-
Major
-
4.14.0
-
None
On https://issues.redhat.com/browse/RFE-2273 the customer analyzed quite correctly:
I have re-reviewed all of the provided data from the attached cases (DHL and ANZ) and have documented my findings below:
1) It looks like the request mentioned by the customer is sent to the Console API. Specifically `api/prometheus-tenancy/api/v1/*`
2) This is then forwarded to Cluster Monitoring (Thanos Querier) [0]
3) Thanos is configured to set the CORS headers to `*` due to the absence of the `--web.disable-cors` argument.[1]
4) The Thanos deployment is managed by the Cluster Monitoring Operator directly [2]
5) When using Postman, we can see the endpoint respond with a `access-control-allow-origin: *` [see image 1]
6) Manually setting the `--web.disable-cors` argument inside the Thanos Querier deployment, the `access-control-allow-origin: *` is removed.
7) Changing the Cluster Monitoring Operator deployment template[4] to include the flag and push the custom image into an OCP 4.10.31 cluster [3]
8) Seems like everything is working and the endpoint is not longer returning the CORS header. [see image 2]
We should set {}web.disable-cors{-} for our thanos deployment. We don't load any cross-origin resources through the console>thanos querier path, so this should just work.
- is related to
-
OBSDOCS-331 Generate monitoring config map reference content for OCP 4.14 release
- Closed
- is triggered by
-
OBSDA-232 Cross Origin Resource Sharing protection for the OpenShift Web Console
- In Progress
- links to
-
RHSA-2023:5006 OpenShift Container Platform 4.14.z security update