NihalJain commented on code in PR #8170: URL: https://github.com/apache/hbase/pull/8170#discussion_r3170625223
########## hbase-website/app/pages/_landing/security-model/content.md: ########## @@ -0,0 +1,139 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +--> + +# Security Model + +This page describes the security model of Apache HBase. It details the assumptions and guarantees the project makes with respect to security. It is intended to help operators deploy HBase safely, to help security researchers understand what constitutes a legitimate vulnerability, and to help the [Apache Security Team](https://www.apache.org/security/) efficiently triage incoming reports. + +This page was created following the [ASF recommendation for documenting project security models](https://cwiki.apache.org/confluence/display/SECURITY/Documenting+your+security+model). + +## Reporting Security Vulnerabilities + +To report an undisclosed, sensitive security vulnerability in Apache HBase, please send your report privately via email to the Apache Software Foundation's security team at [[email protected]](mailto:[email protected]). Please do not use JIRA or any public channel for security reports. + +HBase follows the [Apache Software Foundation's vulnerability handling policy](https://www.apache.org/security/). + +## Assumption: Operator-Secured Production Deployments + +HBase requires operators to configure authentication and authorization for production deployments. This is the foundational assumption of the HBase security model. + +HBase ships with a default configuration that does not enable authentication or authorization. This default exists solely to aid developers, testing, and CI/CD environments. It does not imply under any circumstances that deploying or running HBase without security is safe or desirable for production use. + +No realistic production deployment runs HBase without security configured. The HBase documentation provides [comprehensive guidance on configuring security](/docs/security), including Kerberos authentication, SASL, Access Control Lists (ACLs), and visibility labels. + +Vulnerability reports that assume or require an insecure configuration as part of an attack chain are not valid security reports. Such reports describe the expected behavior of an intentionally unsecured configuration, not a security flaw. + +## Trust Boundaries + +### Network Perimeter + +HBase is designed for deployment within a trusted network perimeter, such as a private datacenter network or a properly configured cloud VPC. HBase services should not be directly exposed to the public internet. + +Operators are responsible for ensuring appropriate network-level controls (firewalls, security groups, network segmentation) are in place around the HBase cluster. + +### Cluster-Internal Trust + +All HBase server-side processes, such as the HMaster and RegionServers, and their communication with ZooKeeper and HDFS, trust each other within a properly configured cluster. Compromising any one of these processes is effectively equivalent to compromising the entire cluster. These are all components of a single distributed system that must cooperate to function. + +Inter-process authentication is enforced via Kerberos/SASL, ensuring only legitimate cluster members can participate. + +### HDFS as Trusted Storage + +HBase relies on HDFS or compatible distributed filesystem, or S3 or S3-alike cloud object storage, as its persistent storage layer. HBase assumes that the underlying storage layer access controls are correctly configured and that the storage layer is part of the same trust domain. An attacker with direct write access to the underlying storage layer can corrupt or manipulate HBase data regardless of HBase-level access controls. + +### Client Trust Boundary + +When authentication and authorization are configured: + +- **Authentication** (Kerberos/SASL) verifies client identity before any operations are permitted. +- **Authorization** (ACLs) controls which authenticated users can perform which operations on which resources. +- Unauthenticated clients are rejected. + +When authentication is not configured, which is only recommended for development or test environments, any client that can reach HBase over the network can perform any operation. This is expected and intentional for that configuration. + +## Gateway Services + +The REST and Thrift gateways are optional services that provide HTTP and Thrift protocol access to HBase. In their default configuration, these gateways do not perform authentication. For production use, operators must configure authentication on these gateways (SPNEGO/Kerberos for REST, SASL for Thrift) and/or restrict network access to them. See [Secure Client Access](/docs/security/client-access) for detailed configuration instructions. The gateways inherit the same trust model as the rest of HBase. When security is not configured, they are open. When security is configured, they enforce authentication and can support impersonation with proper proxy user setup. The REST gateway's `hbase.rest.readonly` flag and the Thrift gateway's security settings are operational controls for the administrator to configure appropriately. + +Reports about unauthenticated access through gateways that have not been configured for authentication describe expected behavior, not a security flaw. + +## Coprocessors + +Coprocessors are a powerful extension mechanism that allows custom code to execute within HBase server processes. Loading a coprocessor is equivalent to granting full server-level access. Coprocessor code runs in the same JVM as the HBase server process with the same privileges. This is by design. Coprocessors are intended for trusted server-side extensions. +Operators control which coprocessors are loaded through server-side configuration (`hbase.coprocessor.region.classes`, `hbase.coprocessor.master.classes`, `hbase.coprocessor.regionserver.classes`) and/or through table descriptors. The [CoprocessorWhitelistMasterObserver](https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/security/access/CoprocessorWhitelistMasterObserver.html) can be used to restrict which coprocessor JARs may be loaded. + +When authorization is configured, only users with appropriate permissions can modify table descriptors, and therefore only authorized users can affect coprocessor loading via table schema changes. The ability to load coprocessors via table descriptors is a feature. When access to table schema modification is restricted by ACLs, as it must be in production, this is not a vulnerability. + +## Web UIs + +The HBase server web UIs are administrative monitoring interfaces. They are designed for use within the trusted network and are helpful for operators and developers. + +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. + Review Comment: before we commit: maybe we should use new book, sorry i shared old book links. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
