Skip to content

HBASE-30130 Add a security-model section to the website#8170

Open
apurtell wants to merge 2 commits intoapache:masterfrom
apurtell:HBASE-30130
Open

HBASE-30130 Add a security-model section to the website#8170
apurtell wants to merge 2 commits intoapache:masterfrom
apurtell:HBASE-30130

Conversation

@apurtell
Copy link
Copy Markdown
Contributor

Add a "Security Model" page to the Apache HBase website, following the ASF Security Team's recommendation for projects to document their security assumptions.

The page defines HBase's trust boundaries, explains that HBase's default unauthenticated configuration is intended only for development and testing, and clarifies security expectations for gateway services, coprocessors, web UIs, and transport encryption. It enumerates what constitutes a valid vulnerability versus what does not, providing clear guidance for operators, security researchers, and the ASF Security Team when triaging incoming reports.

@apurtell apurtell requested a review from PDavid April 29, 2026 20:17
Copy link
Copy Markdown
Member

@raboof raboof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, added a few comments!


## Reporting Security Vulnerabilities

To report an undisclosed, sensitive security vulnerability in Apache HBase, please preferentially send your report to the private mailing list [private@hbase.apache.org](mailto:private@hbase.apache.org). You may also report security vulnerabilities to the Apache Software Foundation's security team privately via email at [security@apache.org](mailto:security@apache.org). Please do not use JIRA or any public channel for security reports.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not ask people to report vulnerabilities to private@hbase.apache.org, but ask them to email security@apache.org.

If you're ready to receive reports 'directly', you can request a project security list (https://security.apache.org/resources/#project-specific-security-lists)


## What Is Considered a Vulnerability

The following categories of issues are considered valid security vulnerabilities and should be reported to [private@hbase.apache.org](mailto:private@hbase.apache.org) or [security@apache.org](mailto:security.apache.org):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same here)

Comment on lines +95 to +96
- **Authorization bypass**: An authenticated user performing operations beyond their granted ACL permissions.
- **Privilege escalation**: An authenticated user with limited permissions gaining administrative or superuser capabilities.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't that kind of the same?

- **Access requiring operator-level cluster configuration changes**: Issues that require modifying `hbase-site.xml` or other server configuration files require host-level access, which is outside the HBase security boundary.
- **Information disclosure via administrative interfaces on trusted networks**: Version information, configuration details, or metrics visible in the web UIs when accessed from within the trusted network.
- **Exposure of services on untrusted networks**: Placing HBase services directly on the public internet without firewalls or VPN is an operator misconfiguration, not a vulnerability.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more things to put in either of the above lists:

  • Are logs intended to be safe to expose to users with read-only authorization, or may they contain credentials?
  • Is it a problem when an unauthenticated user can easily determine the deployed version?
  • Is it OK if an attacker can discover what usernames are valid for the system?

@yuriipalam
Copy link
Copy Markdown
Contributor

Looks good to me from the code perspective 👍


Information exposed through the web UIs, such as software version, configuration properties, table metadata, and operational metrics, is not considered sensitive within HBase's security model because these interfaces are expected to be accessible only within the trusted network perimeter.

The web UI can optionally be configured with SPNEGO authentication. See [Secure Access to HBase Web UIs](/docs/security/web-ui).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also support LDAP for Web UI.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- **Unauthenticated access to unconfigured gateways**: The REST and Thrift gateways operating without authentication when authentication has not been configured.
- **Administrative actions by authorized administrators**: Superusers and global administrators can, by design, perform any operation in the cluster. This includes loading coprocessors, modifying table schemas, and accessing all data.
- **Access requiring operator-level cluster configuration changes**: Issues that require modifying `hbase-site.xml` or other server configuration files require host-level access, which is outside the HBase security boundary.
- **Information disclosure via administrative interfaces on trusted networks**: Version information, configuration details, or metrics visible in the web UIs when accessed from within the trusted network.
Copy link
Copy Markdown
Contributor

@NihalJain NihalJain Apr 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also put logs/conf/metrics and all privileged servlets in general, behind auth by configuring admins.

Refer https://hbase.apache.org/book.html#_defining_administrators_of_the_web_ui_with_ldap. We can add same for SPNEGO its missing today though

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apurtell apurtell requested review from NihalJain and raboof April 30, 2026 19:23
@apurtell
Copy link
Copy Markdown
Contributor Author

Thank you for the recommendations. I think I've incorporated them all.

Information exposed through the web UIs, such as software version, configuration properties, table metadata, and operational metrics, is not considered sensitive within HBase's security model because these interfaces are expected to be accessible only within the trusted network perimeter.

The web UI can optionally be configured with [SPNEGO](https://hbase.apache.org/book.html#hbase.secure.spnego) or [LDAP](https://hbase.apache.org/book.html#hbase.secure.ldap.ui) authentication. Additionally, privileged servlets — including logs, server configuration, metrics, and other administrative endpoints — can be restricted to designated administrators. Both SPNEGO and LDAP support defining administrators who have exclusive access to these servlets. See [Defining Administrators with SPNEGO](https://hbase.apache.org/book.html#_defining_administrators_of_the_web_ui_with_spnego) and [Defining Administrators with LDAP](https://hbase.apache.org/book.html#_defining_administrators_of_the_web_ui_with_ldap) for details.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

before we commit: maybe we should use new book, sorry i shared old book links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants