You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@storm.apache.org by rz...@apache.org on 2026/04/13 17:48:54 UTC
(storm-site) branch main updated: Add security model
This is an automated email from the ASF dual-hosted git repository.
rzo1 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/storm-site.git
The following commit(s) were added to refs/heads/main by this push:
new 0a33a551e7 Add security model
0a33a551e7 is described below
commit 0a33a551e7381bfbda629a2bc79780948c1647cf
Author: Richard Zowalla <rz...@apache.org>
AuthorDate: Mon Apr 13 19:48:45 2026 +0200
Add security model
---
_includes/header.html | 1 +
releases/2.8.6/SECURITY.md | 2 +
security-model.md | 127 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 130 insertions(+)
diff --git a/_includes/header.html b/_includes/header.html
index 2df7941eea..862ff718a9 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -30,6 +30,7 @@
<ul class="nav navbar-nav">
<li><a href="/index.html" id="home">Home</a></li>
<li><a href="/getting-help.html" id="getting-help">Getting Help</a></li>
+ <li><a href="/security-model.html" id="security-model">Security</a></li>
<li><a href="/about/integrates.html" id="project-info">Project Information</a></li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" id="documentation">Documentation <b
diff --git a/releases/2.8.6/SECURITY.md b/releases/2.8.6/SECURITY.md
index 41cf254f74..c9a76d4c06 100644
--- a/releases/2.8.6/SECURITY.md
+++ b/releases/2.8.6/SECURITY.md
@@ -10,6 +10,8 @@ Apache Storm offers a range of configuration options when trying to secure
your cluster. By default all authentication and authorization is disabled but
can be turned on as needed.
+For the assumptions, trust boundaries, and scope of what Storm considers a security vulnerability, see the [Apache Storm Security Model](/security-model.html). Reading it first is recommended before reporting security issues.
+
## Firewall/OS level Security
You can still have a secure storm cluster without turning on formal
diff --git a/security-model.md b/security-model.md
new file mode 100644
index 0000000000..e6c5c152a3
--- /dev/null
+++ b/security-model.md
@@ -0,0 +1,127 @@
+---
+layout: default
+title: Security Model
+---
+# Apache Storm Security Model
+
+This document describes the security model of Apache Storm: the assumptions, trust boundaries, and guarantees the project makes with respect to security. It is intended to help operators deploy Storm securely and to help security researchers understand which behaviors are expected and which constitute genuine vulnerabilities.
+
+For instructions on how to configure Storm's security features, see [Running Apache Storm Securely](https://storm.apache.org/releases/current/SECURITY.html).
+
+## Reporting Security Vulnerabilities
+
+The Apache Software Foundation takes a very active stance in eliminating security problems and denial of service attacks against its products. We strongly encourage people to report security problems privately using the security mailing list of the ASF Security Team before disclosing them in a public forum.
+
+Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem in our source code will be ignored.
+
+Before reporting vulnerabilities, please read and understand this security model. Some potential issues that are valid for internet-facing applications are expected behavior in Storm's deployment model. Understanding the security model helps save time for both reporters and the Storm security team.
+
+The private security mailing address is: [security@apache.org](mailto:security@apache.org)
+
+## Fundamental Assumption: Trusted Deployment Environment
+
+Apache Storm is designed to operate within trusted infrastructure. The cluster, including Nimbus, Supervisors, Workers, ZooKeeper, the Storm UI, and the Logviewer, is expected to run on a private network that is not directly accessible from the public internet. All components are intended to be accessed only by authorized operators and applications within the trusted network boundary.
+
+This assumption underpins the entire security model. Many components do not include defenses against attacks that assume public internet exposure, because such exposure falls outside the intended deployment model.
+
+## Trusted Configuration
+
+The Storm configuration file (`storm.yaml`) is treated as a fully trusted input. An actor with write access to `storm.yaml` has effective administrative control over the entire Storm cluster, including the ability to reconfigure any component, change authentication and authorization settings, alter network bindings, and disable security features entirely.
+
+Protecting `storm.yaml` through file system permissions and OS-level access controls is an operational responsibility. Modification of this file by an unauthorized party implies a deeper infrastructure compromise and is out of scope for Storm's runtime security protections.
+
+This applies equally to other configuration files used by Storm, such as `multitenant-scheduler.yaml`, JAAS configuration files, and DRPC ACL files.
+
+## User Types and Trust Levels
+
+### Deployment Managers / Cluster Administrators
+
+Deployment managers have the highest level of access and control. They install and configure Storm, manage `storm.yaml`, and make decisions about authentication, authorization, and network topology. They are trusted with full control of the cluster. Their responsibilities include securing the configuration files, setting up appropriate authentication mechanisms, restricting network access to cluster components, and configuring reverse proxies where necessary.
+
+### Topology Submitters
+
+Users who submit topologies execute arbitrary code on Storm workers. This model inherently trusts topology submitters; they can run any code within the context of the worker process. When multi-tenancy is required, the multi-tenant scheduler and `supervisor.run.worker.as.user` settings provide OS-level isolation, but topology submitters must still be authorized and trusted users.
+
+Access to topology submission should be restricted to trusted users via Kerberos authentication and the `SimpleACLAuthorizer` (or equivalent), and further limited through `nimbus.users` and `nimbus.groups`.
+
+### UI / API Users
+
+Users who access the Storm UI or REST API can view cluster state and, depending on authorization, perform state-changing operations such as killing, activating, deactivating, or rebalancing topologies. Authenticated UI users with administrative privileges are trusted to perform these operations. The Storm UI does not guarantee protection against actions initiated by the authenticated user themselves.
+
+## Storm UI, Logviewer, and DRPC HTTP
+
+### Not Internet-Facing
+
+The Storm UI (default port 8080), Logviewer (default port 8000), and DRPC HTTP endpoint are internal cluster services. They must not be exposed to the public internet. Operators should restrict access to these ports using firewall rules, limiting connections to trusted hosts within the cluster network.
+
+### Reverse Proxy Recommended
+
+For production deployments, these services should be placed behind a reverse proxy such as Apache httpd or nginx. The reverse proxy should provide TLS termination with current cipher suites, CSRF token validation or same-origin enforcement, security response headers (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy`, `Strict-Transport-Security`), rate limiting and request filtering, and centralized access logging.
+
+### CORS and Same-Origin Policy
+
+The Storm UI sets permissive CORS headers (`Access-Control-Allow-Origin: *`) by default. This is acceptable within the trusted network model where the UI is not internet-accessible. Operators who need stricter origin controls should configure them at the reverse proxy layer. This is documented behavior, not a vulnerability.
+
+### CSRF Protection
+
+The Storm UI REST API does not include built-in Cross-Site Request Forgery protection. Because the UI is designed to be accessible only from within a trusted network, CSRF risk is mitigated by network-level access controls. Operators requiring additional CSRF protection should configure it via their reverse proxy or a custom servlet filter through `ui.filter`. We do strive to follow HTTP semantics (using POST for state-changing operations) and welcome hardening reports in this area.
+
+### Authentication
+
+By default, the Storm UI has no authentication enabled. Operators should configure a servlet filter via `ui.filter` (for example, using Kerberos/SPNEGO via `AuthenticationFilter` from hadoop-auth) or rely on their reverse proxy for authentication. The Storm UI is not safe to operate without authentication if any untrusted user can reach it.
+
+## Logs and Information Disclosure
+
+Storm logs may contain sensitive information including stack traces with internal paths and class names, configuration values, topology data, and credentials or tokens if passed through tuple data. Logs are not intended to be safe for exposure to untrusted users. Access to the Logviewer should be restricted to authorized operators through the same mechanisms used for the UI (authentication filters, network restrictions, or reverse proxy controls). The `logs.users` and `logs.groups` setti [...]
+
+## Authentication and Authorization
+
+Storm provides pluggable authentication via Kerberos/SASL and pluggable authorization via `SimpleACLAuthorizer`. By default, both are disabled. Operating Storm without authentication and authorization is only appropriate in fully trusted, single-tenant environments where all network access is controlled. In multi-tenant or security-sensitive deployments, operators must enable Kerberos authentication, configure `SimpleACLAuthorizer` on Nimbus, configure `ImpersonationAuthorizer` if impers [...]
+
+Storm does not protect against brute-force password guessing or account enumeration. These protections should be provided at the infrastructure level (Kerberos KDC configuration, network controls, or reverse proxy rate limiting).
+
+## Impersonation
+
+Storm supports user impersonation (submitting requests on behalf of another user). Without `nimbus.impersonation.authorizer` configured, any authenticated user can impersonate any other user. When deploying a secured cluster, operators must always configure `nimbus.impersonation.authorizer` alongside `nimbus.authorizer`.
+
+## Serialization
+
+Storm uses Kryo for tuple serialization. The setting `topology.fall.back.on.java.serialization` must not be set to `true` in production, as Java native deserialization is vulnerable to arbitrary code execution from untrusted data. Storm defaults to requiring explicit class registration, which is the safe configuration.
+
+## ZooKeeper Communication
+
+When ZooKeeper SSL is enabled, hostname verification is disabled by default (`storm.zookeeper.ssl.hostnameVerification: false`). Without hostname verification, a man-in-the-middle attacker with any valid CA-signed certificate could intercept Storm-to-ZooKeeper communication. Production deployments should enable hostname verification.
+
+## Network Encryption
+
+Storm supports TLS for Thrift RPC communication (Nimbus, Supervisors) and Netty messaging (worker-to-worker) via mTLS. Enabling transport encryption is recommended for deployments where network traffic may traverse untrusted segments. The deprecated `BlowfishTupleSerializer` should not be used; it employs a 64-bit block cipher vulnerable to birthday attacks.
+
+## Test Utilities in Production JARs
+
+Storm includes certain classes intended for development and testing (such as `TestingFilter`) in its production JAR. These classes can be enabled through `storm.yaml` configuration. Since `storm.yaml` is a trusted input, the ability to enable test utilities through configuration is not a security vulnerability; it is equivalent to any other configuration change an administrator can make. However, operators should be aware that misconfiguring these settings can weaken security.
+
+## What Is and Is Not a Security Vulnerability
+
+Based on this security model, the following are **not** considered security vulnerabilities:
+
+- Issues that require write access to `storm.yaml` or other trusted configuration files.
+- Issues that require the Storm UI, Logviewer, or DRPC HTTP endpoints to be exposed to the public internet, contrary to deployment guidance.
+- Permissive default CORS headers on internal services that are not intended to be internet-facing.
+- Absence of built-in CSRF protection on internal services behind network-level access controls.
+- Information disclosure through logs or API endpoints that are restricted to trusted network access.
+- Enabling test utilities through configuration (which requires trusted configuration access).
+- Version disclosure on internal endpoints.
+
+The following **are** considered security vulnerabilities and should be reported:
+
+- Authentication or authorization bypass that does not require trusted configuration access.
+- Privilege escalation within the authorization model (for example, a non-admin user gaining admin capabilities without configuration changes).
+- Remote code execution through untrusted input processed by Storm components (not topology code submitted by trusted users).
+- Issues that compromise the security of a cluster deployed according to our documented recommendations.
+
+We welcome security hardening suggestions even for areas outside the formal vulnerability scope. Reports that improve HTTP semantics compliance, add defense-in-depth measures, or improve the security posture of the default configuration are appreciated and will be addressed as hardening improvements.
+
+## Questions About Known Security Problems
+
+Questions about whether a vulnerability applies to your particular deployment, obtaining further information on a published vulnerability, or availability of patches and new releases should be addressed to the [dev mailing list](https://storm.apache.org/community.html).
+