mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-17 10:17:55 +00:00
Zhengchao An
a9691b6797
backlog#1823 step 10, batch 1 of the repo-wide item-allow sweep. 227 bare #[allow(dead_code)] remain across 83 files; this takes the 19 in utils, notify, checksums, policy, keystone and trusted-proxies, which are small enough to verify end to end. Removing all 19 first, before writing any reason, matters: 8 of them suppress nothing. Every allow in utils, one in policy and three in notify sit on items that are publicly reachable, so dead_code never applied to them — the same shape as the swift module and kms's dek.rs. Writing a reason onto a no-op allow would dress noise up as considered judgement, so those are simply deleted. Three items are genuinely dead and go with their allows: notify's new_target_id_set, the AWS metadata fetcher's get_metadata_token, and policy's empty `pub struct Value;`, none of which is referenced anywhere in the tree. The remaining eight keep an allow, now saying why the item survives rather than who calls it. Two are exercised only by their own crate's tests (checksums' MD5_HEADER_NAME, policy's is_match_as_pattern_prefix). Four are fields written but never read back: keystone's verify_ssl, parsed from config after the reqwest client is already built; keystone's client handle, which keeps the Keystone client alive for the mapper's lifetime; the AWS IMDS endpoint, kept beside the client while requests build their own URLs; and notify's rules_map, whose own comment retains it for snapshot-time judgements no code performs. checksums' Md5 needed the most care. Crc32, Sha256 and seven others each have an arm in ChecksumAlgorithm::into_impl, and Md5 has none, which reads like a missing algorithm. It is not: ChecksumAlgorithm has no Md5 variant at all. S3 carries Content-MD5 as its own header, separate from the x-amz-checksum-* family, and this impl exists so both paths share the Checksum trait. The reason records that, so the next reader does not re-derive it. One measurement note for anyone continuing this sweep: cargo does not re-emit warnings for cached compilations, so a per-crate loop of `cargo check -p <crate>` under-reports. checksums showed zero that way while actually carrying three. Touch the sources and check the crates in one invocation, then attribute by path. Verification: the six crates are warning-free under cargo check --tests; clippy --lib --tests -D warnings clean; cargo nextest run 1096 passed; make pre-commit exit 0. Ref rustfs/backlog#1823 (step 10).
RustFS Trusted Proxies
The rustfs-trusted-proxies module provides secure and efficient management of trusted proxy servers within the RustFS
ecosystem. It is designed to handle multi-layer proxy architectures, ensuring accurate client IP identification while
maintaining a zero-trust security model.
Modes
- Simple default: only trusts forwarding headers when the direct peer IP is internal.
- Legacy full mode: keeps the original proxy-chain validation, available
via
legacy_*helpers.
Features
- Multi-Layer Proxy Validation: Supports
Strict,Lenient, andHopByHopvalidation modes to accurately identify the real client IP address. - Zero-Trust Security: Verifies every hop in the proxy chain against a configurable list of trusted networks.
- Cloud Integration: Automatic discovery of trusted IP ranges for major cloud providers including AWS, Azure, and GCP.
- High Performance: Utilizes the
mokacache for fast lookup of validation results andaxumfor a high-performance web interface. - Observability: Built-in support for Prometheus metrics and structured JSON logging via
tracing. - RFC 7239 Support: Full support for the modern
Forwardedheader alongside legacyX-Forwarded-Forheaders.
Configuration
The module is configured primarily through environment variables:
| Variable | Default | Description |
|---|---|---|
RUSTFS_TRUSTED_PROXY_ENABLED |
true |
Enable the trusted proxy middleware |
RUSTFS_TRUSTED_PROXY_IMPLEMENTATION |
simple |
Select simple or legacy implementation |
RUSTFS_TRUSTED_PROXY_VALIDATION_MODE |
hop_by_hop |
Validation strategy (strict, lenient, hop_by_hop) |
RUSTFS_TRUSTED_PROXY_NETWORKS |
127.0.0.1,::1 |
Comma-separated list of trusted CIDR ranges (loopback-only by default) |
RUSTFS_TRUSTED_PROXY_MAX_HOPS |
10 |
Maximum allowed proxy hops |
RUSTFS_TRUSTED_PROXY_CACHE_CAPACITY |
10000 |
Max entries in the validation cache |
RUSTFS_TRUSTED_PROXY_METRICS_ENABLED |
true |
Enable Prometheus metrics collection |
RUSTFS_TRUSTED_PROXY_CLOUD_METADATA_ENABLED |
false |
Enable auto-discovery of cloud IP ranges |
Usage
Initialization
Initialize the global trusted proxy system at the start of your application (e.g., in main.rs):
// Initialize trusted proxies system
rustfs_trusted_proxies::init();
As a Middleware
Integrate the trusted proxy validation into your Axum application or HTTP service stack:
use rustfs_trusted_proxies;
let app = Router::new()
.route("/", get(handler))
// Add the trusted proxy layer if enabled
.option_layer(if rustfs_trusted_proxies::is_enabled() {
Some(rustfs_trusted_proxies::layer().clone())
} else {
None
});
Simple default mode
The default mode only trusts forwarding headers from internal IPs.
RUSTFS_TRUSTED_PROXY_IMPLEMENTATION=simple
Legacy mode
The original implementation is still available:
rustfs_trusted_proxies::legacy_init();
let layer = rustfs_trusted_proxies::LegacyTrustedProxyLayer::enabled(config, None);
Or switch the global default path:
RUSTFS_TRUSTED_PROXY_IMPLEMENTATION=legacy
Accessing Client Info
Retrieve the verified client information in your handlers or other middleware:
use rustfs_trusted_proxies::ClientInfo;
async fn handler(req: Request) -> impl IntoResponse {
if let Some(client_info) = req.extensions().get::<ClientInfo>() {
println!("Real Client IP: {}", client_info.real_ip);
println!("Is Trusted: {}", client_info.is_from_trusted_proxy);
}
}
Development
Pre-Commit Checklist
Before committing, ensure all checks pass:
make pre-commit
Testing
Run the test suite:
cargo test --workspace --exclude e2e_test
License
Licensed under the Apache License, Version 2.0.