suneet-s commented on a change in pull request #11016: URL: https://github.com/apache/druid/pull/11016#discussion_r610331091
########## File path: docs/operations/security-overview.md ########## @@ -23,66 +24,112 @@ title: "Security overview" --> -## Overview + +This document provides an overview of Apache Druid security features, configuration instructions, and some best practices to secure Druid. By default, security features in Druid are disabled, which simplifies the initial deployment experience. However, security features must be configured in a production deployment. These features include TLS, authentication, and authorization. -To implement Druid security, you configure authenticators and authorizers. Authenticators control the way user identities are verified, while authorizers map the authenticated users (via user roles) to the datasources they are permitted to access. Consequently, implementing Druid security also involves considering your datasource scheme, since that scheme represents the granularity at which data access permissions are allocated. -The following graphic depicts the course of request through the authentication process: +## Best practices +The following recommendations apply to the Druid cluster setup: +* Run Druid as an unprivileged Unix user. Do not run Druid as the root user. + > **WARNING!** \ + Druid administrators have the same OS permissions as the Unix user account running Druid. See [Authentication and authorization model](security-user-auth.md#authentication-and-authorization-model). If the Druid process is running under the OS root user account, then Druid administrators can read or write all files that the root account has access to, including sensitive files such as `/etc/passwd`. +* Enable authentication to the Druid cluster for production environments and other environments that can be accessed by untrusted networks. +* Enable authorization and do not expose the Druid Console without authorization enabled. If authorization is not enabled, any user that has access to the web console has the same privileges as the operating system user that runs the Druid Console process. +* Grant users the minimum permissions necessary to perform their functions. For instance, do not allow users who only need to query data to write to data sources or view state. +* * Disable JavaScript, as noted in the [Security section](https://druid.apache.org/docs/latest/development/javascript.html#security) of the JavaScript guide. + +The following recommendations apply the network where Druid runs: Review comment: ```suggestion The following recommendations apply to the network where Druid runs: ``` ########## File path: docs/operations/security-overview.md ########## @@ -23,66 +24,112 @@ title: "Security overview" --> -## Overview + +This document provides an overview of Apache Druid security features, configuration instructions, and some best practices to secure Druid. By default, security features in Druid are disabled, which simplifies the initial deployment experience. However, security features must be configured in a production deployment. These features include TLS, authentication, and authorization. -To implement Druid security, you configure authenticators and authorizers. Authenticators control the way user identities are verified, while authorizers map the authenticated users (via user roles) to the datasources they are permitted to access. Consequently, implementing Druid security also involves considering your datasource scheme, since that scheme represents the granularity at which data access permissions are allocated. -The following graphic depicts the course of request through the authentication process: +## Best practices +The following recommendations apply to the Druid cluster setup: +* Run Druid as an unprivileged Unix user. Do not run Druid as the root user. + > **WARNING!** \ + Druid administrators have the same OS permissions as the Unix user account running Druid. See [Authentication and authorization model](security-user-auth.md#authentication-and-authorization-model). If the Druid process is running under the OS root user account, then Druid administrators can read or write all files that the root account has access to, including sensitive files such as `/etc/passwd`. +* Enable authentication to the Druid cluster for production environments and other environments that can be accessed by untrusted networks. +* Enable authorization and do not expose the Druid Console without authorization enabled. If authorization is not enabled, any user that has access to the web console has the same privileges as the operating system user that runs the Druid Console process. +* Grant users the minimum permissions necessary to perform their functions. For instance, do not allow users who only need to query data to write to data sources or view state. +* * Disable JavaScript, as noted in the [Security section](https://druid.apache.org/docs/latest/development/javascript.html#security) of the JavaScript guide. Review comment: ```suggestion * Disable JavaScript, as noted in the [Security section](https://druid.apache.org/docs/latest/development/javascript.html#security) of the JavaScript guide. ``` ########## File path: docs/operations/security-overview.md ########## @@ -23,66 +24,112 @@ title: "Security overview" --> -## Overview + +This document provides an overview of Apache Druid security features, configuration instructions, and some best practices to secure Druid. By default, security features in Druid are disabled, which simplifies the initial deployment experience. However, security features must be configured in a production deployment. These features include TLS, authentication, and authorization. -To implement Druid security, you configure authenticators and authorizers. Authenticators control the way user identities are verified, while authorizers map the authenticated users (via user roles) to the datasources they are permitted to access. Consequently, implementing Druid security also involves considering your datasource scheme, since that scheme represents the granularity at which data access permissions are allocated. -The following graphic depicts the course of request through the authentication process: +## Best practices +The following recommendations apply to the Druid cluster setup: +* Run Druid as an unprivileged Unix user. Do not run Druid as the root user. + > **WARNING!** \ + Druid administrators have the same OS permissions as the Unix user account running Druid. See [Authentication and authorization model](security-user-auth.md#authentication-and-authorization-model). If the Druid process is running under the OS root user account, then Druid administrators can read or write all files that the root account has access to, including sensitive files such as `/etc/passwd`. +* Enable authentication to the Druid cluster for production environments and other environments that can be accessed by untrusted networks. +* Enable authorization and do not expose the Druid Console without authorization enabled. If authorization is not enabled, any user that has access to the web console has the same privileges as the operating system user that runs the Druid Console process. +* Grant users the minimum permissions necessary to perform their functions. For instance, do not allow users who only need to query data to write to data sources or view state. +* * Disable JavaScript, as noted in the [Security section](https://druid.apache.org/docs/latest/development/javascript.html#security) of the JavaScript guide. + +The following recommendations apply the network where Druid runs: +* Enable TLS to encrypt communication within the cluster. +* Use an API gateway to: + - Restrict access from untrusted networks + - Create an allow list of specific APIs that your users need to access + - Implement account lockout and throttling features. +* When possible, use firewall and other network layer filtering to only expose Druid services and ports specifically required for your use case. For example, only expose Broker ports to downstream applications that execute queries. You can limit access to a specific IP address or IP range to further tighten and enhance security. Review comment: The previous bullet and this one make the same point, just with different technologies. I think we should collapse them and tell operators they can use either an API gateway, or a firewall or something else... ########## File path: docs/operations/security-overview.md ########## @@ -264,3 +322,31 @@ As an alternative to using the basic metadata authenticator, as shown in the pre Congratulations, you have configured permissions for user-assigned roles in Druid! + + +## Druid security trust model +Within Druid's trust model there users can have different authorization levels: +- Users with resource write permissions can are allowed to anything that the druid process can do. Review comment: ```suggestion - Users with resource write permissions can are allowed to do anything that the druid process can do. ``` ########## File path: docs/operations/security-overview.md ########## @@ -136,37 +193,37 @@ The following steps walk through a sample setup procedure: > The default Coordinator API port is 8081 for non-TLS connections and 8281 > for secured connections. -1. Create a user by issuing a POST request to `druid-ext/basic-security/authentication/db/MyBasicMetadataAuthenticator/users/<USERNAME>`, replacing USERNAME with the new username. For example: +1. Create a user by issuing a POST request to `druid-ext/basic-security/authentication/db/MyBasicMetadataAuthenticator/users/<USERNAME>`, replacing USERNAME with the *new* username you are trying to create. For example: Review comment: This example talks about using the druid basic security extension. The rest of this doc talks about principles that apply across Druid. It feels like we want to separate this into separate pages. Since this example already existed in this page, I don't think we need to move it in this PR, but perhaps in a follow up one. -- 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. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
