Which OpenObserve functionalities are relevant/related to the feature request?
other
Description
Problem Statement
We are evaluating OpenObserve for use in a highly secure, regulated environment that strictly mandates FIPS (Federal Information Processing Standards) compliance. To meet these requirements, all cryptographic operations (TLS termination, data-at-rest encryption, etc.) must utilize validated cryptographic modules.
We have successfully built a custom OpenObserve image using a Chainguard Rust-FIPS base image where libcrypto.so is FIPS-validated. However, we are unsure if this build is fully FIPS-compliant out-of-the-box due to how Rust manages cryptographic dependencies.
Request
I am looking for architectural clarity or guidance from the maintainers on how OpenObserve handles cryptography internally, and whether our compilation strategy is structurally sufficient for FIPS validation.
Proposed solution
To help us verify compliance, we would appreciate clarity or documentation on the following engineering aspects of OpenObserve:
- Crypto Crate Dependency Tree: Does OpenObserve rely heavily on pure-Rust cryptographic libraries like
ring, rustls, or RustCrypto? (Pure-Rust crates bypass host-level libcrypto.so and are generally not FIPS certifiable without specific compatibility shims).
- OpenSSL/BoringSSL Ingestion: If OpenObserve uses pure-Rust crypto, is there a supported build configuration, feature flag, or target override to force the compilation to bind exclusively to native OpenSSL/libcrypto dependencies?
- Data-at-Rest & Storage Encryption: When writing Parquet files or sending data to object storage, does the internal engine rely on system-linked OpenSSL algorithms, or are these operations statically compiled inside Rust sub-crates?
Ideally, having an official recommendation or a standard compilation flag (e.g., forcing OpenSSL backends over native Rust features) would make it significantly easier for enterprise users to deploy OpenObserve in federal or regulated spaces.
Alternatives considered
None
Which OpenObserve functionalities are relevant/related to the feature request?
other
Description
Problem Statement
We are evaluating OpenObserve for use in a highly secure, regulated environment that strictly mandates FIPS (Federal Information Processing Standards) compliance. To meet these requirements, all cryptographic operations (TLS termination, data-at-rest encryption, etc.) must utilize validated cryptographic modules.
We have successfully built a custom OpenObserve image using a Chainguard Rust-FIPS base image where
libcrypto.sois FIPS-validated. However, we are unsure if this build is fully FIPS-compliant out-of-the-box due to how Rust manages cryptographic dependencies.Request
I am looking for architectural clarity or guidance from the maintainers on how OpenObserve handles cryptography internally, and whether our compilation strategy is structurally sufficient for FIPS validation.
Proposed solution
To help us verify compliance, we would appreciate clarity or documentation on the following engineering aspects of OpenObserve:
ring,rustls, orRustCrypto? (Pure-Rust crates bypass host-levellibcrypto.soand are generally not FIPS certifiable without specific compatibility shims).Ideally, having an official recommendation or a standard compilation flag (e.g., forcing OpenSSL backends over native Rust features) would make it significantly easier for enterprise users to deploy OpenObserve in federal or regulated spaces.
Alternatives considered
None