https://openobserve.ai/ logo
Join Slack
Powered by
Hi team, I’m deploying OpenObserve on EKS and want...
# openobserve
s
Hi team, I’m deploying OpenObserve on EKS and want to restrict data ingestion to only specific app/domains (similar to CORS allowlist). Is there any env variable or config to whitelist allowed domains? I couldn’t find this in the docs
m
What datasources you plan to integrate?(Fluentbit, prometheus , OTLP,.. via API) or RUM What specifically do you want to restrict? Certain Apps or network level restriction like domain or IP Typically speaking O2 uses authentication tokens for ingestion and only apps with valid token can ingest. If you are looking for (K8s service) network level restriction then it would go by a gateway route like ingress. cc: @Md Mosaraf (OpenObserve)
s
My use case is to allow data ingestion only from 
<http://www.example.com|www.example.com>
, so even if the token is exposed, requests from other domains/origins shouldn’t be able to send data. This is mainly for RUM (frontend errors & sessions) and backend logs.
m
For backend services running in K8s I think we would require network policies in place so only K8s pods with label can reach O2. For RUM @Patel Bhargav Jayantibhai Can you confirm if we support any CORS configuration to restrict browser ingestion?
For RUM - Currently there is no CORS configuration available within O2, but I discussed with the team and we can add this soon. As a workaround, since we are deploying in K8s you should be able to validate the Origin or Referer header before requests reach ingester, There are few approaches for this like either we can validate at the ingress layer or add a Load Balancer (ALB) service with Custom Rules.
m
if you are using nginx ingress, then you should be able to blocklist or whitelist it at ingress for http_origin
s
Ok got it Thanks @Manas (OpenObserve) and @Md Mosaraf (OpenObserve) for your workaround
Hi @Manas (OpenObserve) Do you have recommended baseline production environment variables / values.yaml settings for OpenObserve that can handle around 50K users per day mostly usage is [RUM (frontend errors & sessions) and backend logs ]? I’m looking for an initial, ideal configuration to start with in production, which I can fine-tune later based on load testing. Any guidance or best practices would be really helpful. Thanks!
Hi @Manas (OpenObserve), Just wanted to confirm if CORS configuration is supported in the latest O2 version. I’m currently facing a CORS issue while sending RUM log requests — the request returns 200, but the browser still shows a CORS error in the console. Is there any documentation available for configuring this? Also, which environment variables need to be set for enabling CORS properly? FYI : my openobserve is in other domain and app is in another domain
m
Just to be aligned, CORS is configured to accept a specific header ( nginx.ingress.kubernetes.io/cors-allow-headers or nginx.ingress.kubernetes.io/cors-allow-origin) - you need to make sure your OpenObserve instance allows requests from your application domain via nginx or any equivalent of that. @Md Mosaraf (OpenObserve) /@Patel Bhargav Jayantibhai - May have some more guidance, please share when you have the chance.
s
In Code base used ZO_CORS_ALLOWED_ORIGINS but no reference in DOC about this environment variable can someone please help here
s
Copy code
ZO_CORS_ALLOWED_ORIGINS — comma-separated list of extra CORS origins allowed alongside ZO_WEB_URL.

Default: "" (empty → no extra origins)

How it works:

CORS middleware checks Origin header against ZO_WEB_URL first
If no match, iterates each origin listed in ZO_CORS_ALLOWED_ORIGINS
Both checks extract <scheme://host>[:port] (no path) for exact byte comparison — prevents prefix-match bypasses
Example:


ZO_CORS_ALLOWED_ORIGINS=<http://localhost:8081>,<https://staging.example.com>
Open in Slack
PreviousNext
Powered by