Document security setup for Arrow Flight RPC transport

[rishabhmaurya]

Description

Addresses a documentation gap identified in the Arrow Flight RPC security setup. The existing security-integration.md lacked explicit warnings about the security implications of using FLIGHT (non-secure) mode vs FLIGHT-SECURE.

Changes

• Add warning that FLIGHT mode bypasses transport-layer encryption
• Add transport modes comparison table (FLIGHT vs FLIGHT-SECURE)

Testing

Documentation-only change. No code changes.

Check List

• New functionality includes testing
  • N/A — documentation only
• New functionality has been documented
• Commits are signed off

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Missing Setting The checklist mentions omitting flight.ssl.enable: true leaves the port unencrypted, but does not document what happens when opensearch.experimental.feature.transport.stream.enabled is omitted or set to false. Readers may benefit from knowing the behavior in that case. Missing any of these settings results in an insecure configuration. Specifically: - Omitting `flight.ssl.enable: true` — TLS defaults to **disabled** (`false`), leaving the Flight port unencrypted - Using `FLIGHT` instead of `FLIGHT-SECURE` — starts the transport without TLS regardless of other settings Port Range Accuracy The introduction states the Flight transport operates on a dedicated port range 9400-9500. This should be verified for accuracy — if it is a single default port rather than a range, the documentation could be misleading. The Arrow Flight RPC plugin integrates with the OpenSearch Security plugin to provide secure streaming transport with TLS encryption. The Flight transport operates on a dedicated port (default `9400-9500`) for internal node-to-node communication, similar to the standard transport on port `9300`.

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Fix contradictory security enforcement statement The statement "apply regardless of the transport type" contradicts the following sentence that says protections "work correctly when the cluster is properly configured with FLIGHT-SECURE". This inconsistency could mislead users into thinking RBAC/DLS/FLS are sufficient even without TLS. Clarify that while the action filter applies to both modes, a fully secure deployment still requires FLIGHT-SECURE. plugins/arrow-flight-rpc/docs/security-integration.md [84] -These security controls are enforced at the action filter layer (SecurityFilter) and apply regardless of the transport type. RBAC, DLS, and FLS protections work correctly when the cluster is properly configured with `FLIGHT-SECURE`. +These security controls are enforced at the action filter layer (SecurityFilter) and apply to both `FLIGHT` and `FLIGHT-SECURE` transport modes. However, RBAC, DLS, and FLS protections alone are insufficient without TLS — a fully secure deployment requires `FLIGHT-SECURE` to also protect the connection layer. Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a genuine contradiction between "apply regardless of the transport type" and "work correctly when the cluster is properly configured with FLIGHT-SECURE". The improved text more accurately conveys that action filters apply to both modes but TLS is still required for full security.	Low
	Clarify ambiguous default port range A port range like 9400-9500 is unusual for a single dedicated port and may confuse readers. If the Flight transport uses a single default port, specify it precisely (e.g., 9400); if it truly uses a range, clarify why and how the port is selected within that range. plugins/arrow-flight-rpc/docs/security-integration.md [3] -The Flight transport operates on a dedicated port (default `9400-9500`) for internal node-to-node communication +The Flight transport operates on a dedicated port (default `9400`) for internal node-to-node communication Suggestion importance[1-10]: 4 __ Why: The port range 9400-9500 is indeed ambiguous and could confuse readers. However, this may be intentional if the plugin dynamically selects a port within that range, so the suggestion to change it to a single port could be inaccurate without more context.	Low

[github-actions]

✅ Gradle check result for a46b356: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.35%. Comparing base (dcd0986) to head (a46b356).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21314      +/-   ##
============================================
- Coverage     73.36%   73.35%   -0.01%     
- Complexity    73874    74039     +165     
============================================
  Files          5943     5948       +5     
  Lines        336172   336526     +354     
  Branches      48484    48552      +68     
============================================
+ Hits         246616   246866     +250     
- Misses        69882    69941      +59     
- Partials      19674    19719      +45     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.