You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by GitBox <gi...@apache.org> on 2022/08/22 17:02:04 UTC
[GitHub] [hbase] anmolnar opened a new pull request, #4717: HBASE-27226 Document native TLS support in Netty RPC
anmolnar opened a new pull request, #4717:
URL: https://github.com/apache/hbase/pull/4717
TLS docs.
cc @Apache9 @bbeaudreault @meszibalu @petersomogyi
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1224104672
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 22s | Docker mode activated. |
||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. |
||| _ master Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 45s | master passed |
| +0 :ok: | refguide | 2m 18s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 43s | branch has no errors when running spotless:check. |
||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 46s | the patch passed |
| +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. |
| +0 :ok: | refguide | 2m 38s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 40s | patch has no errors when running spotless:check. |
||| _ Other Tests _ |
| +1 :green_heart: | asflicense | 0m 11s | The patch does not generate ASF License warnings. |
| | | 13m 45s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | dupname asflicense refguide spotless |
| uname | Linux 9fc7b4dd5c65 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 950ad8dd3e |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/2/yetus-general-check/output/branch-site/book.html |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/2/yetus-general-check/output/patch-site/book.html |
| Max. process+thread count | 64 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1222658863
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 3m 20s | Docker mode activated. |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 4m 22s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux dc9f49b90faf 5.4.0-1071-aws #76~18.04.1-Ubuntu SMP Mon Mar 28 17:49:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 00a719e76f |
| Max. process+thread count | 33 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] bbeaudreault commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
bbeaudreault commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r952634498
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to setup the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient is perfect valid to generate
+our own private/public keypairs and set them up specifically for the HBase cluster. Especially if we don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node with `supportplaintext=True`. Restart the Master.
Review Comment:
Good idea @Apache9. I logged an issue for that: https://issues.apache.org/jira/browse/HBASE-27318
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1222655835
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 38s | Docker mode activated. |
| -0 :warning: | yetus | 0m 4s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 1m 47s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux ae3710ef01b5 5.4.0-1081-aws #88~18.04.1-Ubuntu SMP Thu Jun 23 16:29:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 00a719e76f |
| Max. process+thread count | 37 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r954941131
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart RSs in rolling restart fashion. RSs accepts both TLS/non-TLS communication.
+
+[start=4]
+. Enable secure communication on the clients.
+
+. Enable client-mode TLS on master and disable plaintext mode.
Review Comment:
Actually you don't need to explicitly number the steps if you only have a single blank line between them. Adoc with will do the numbering right. But given that you asked for xml example, I'll have to add the "start" annotation too. ;)
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1234267079
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 25s | Docker mode activated. |
||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. |
||| _ master Compile Tests _ |
| +1 :green_heart: | mvninstall | 3m 2s | master passed |
| +0 :ok: | refguide | 3m 18s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 49s | branch has no errors when running spotless:check. |
||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 42s | the patch passed |
| +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. |
| +0 :ok: | refguide | 2m 51s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 48s | patch has no errors when running spotless:check. |
||| _ Other Tests _ |
| +1 :green_heart: | asflicense | 0m 14s | The patch does not generate ASF License warnings. |
| | | 15m 9s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | dupname asflicense refguide spotless |
| uname | Linux 01d50a4e1592 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 308cd729d2 |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/4/yetus-general-check/output/branch-site/book.html |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/4/yetus-general-check/output/patch-site/book.html |
| Max. process+thread count | 64 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1231470509
@bbeaudreault Are u happy to commit this patch?
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] bbeaudreault commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
bbeaudreault commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r951727263
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
Review Comment:
Note: I am probably going to implement authentication support before 2.6.0. But we can keep this as is for now, I'll update once that lands.
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to setup the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient is perfect valid to generate
+our own private/public keypairs and set them up specifically for the HBase cluster. Especially if we don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node with `supportplaintext=True`. Restart the Master.
Review Comment:
It is probably also worth calling out somewhere that once `hbase.client.netty.tls.enabled` is enabled on the server side, the cluster will only be able to communicate with other clusters which have TLS enabled. For example, this would impact intra-cluster replication.
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to setup the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient is perfect valid to generate
+our own private/public keypairs and set them up specifically for the HBase cluster. Especially if we don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node with `supportplaintext=True`. Restart the Master.
Review Comment:
I actually think there needs to be more steps here, because the server side actually is impacted by both `hbase.client.netty.tls.enabled` AND `hbase.server.netty.tls.enabled`. If in this step you enable both, the HMaster will not be able to communicate with RegionServers (who will be enabled below). If you only enable server side, when you get to the "disable plaintext" step below you'll start to see failures because regionservers will be trying to communicate with the HMaster over plaintext.
So really the user needs to fully restart the cluster a few times:
1. Enable `hbase.server.netty.tls.enabled` only, with supportPlaintext=true. Servers will _accept_ TLS, but not _send_ TLS..
2. Additionally enable `hbase.client.netty.tls.enabled` on servers, keeping supportPlaintext=true. Servers will now _accept and send_ TLS.
3. Remove supportPlaintext=true. Servers will reject requests if not TLS.
Clients can be updated to use `hbase.client.netty.tls.enabled` either after step 1 or 2, but before 3.
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
Review Comment:
It may be worth calling out that the users should make sure their hbase-site.xml has appropriate permissions since we're now putting a password in it. We could leave that out, but just thinking you went into such detail on the other stuff below that maybe it makes sense to mention.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1224090084
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 1m 16s | Docker mode activated. |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 2m 24s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux 0e2d3a38a8b2 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 950ad8dd3e |
| Max. process+thread count | 37 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1227246178
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 38s | Docker mode activated. |
| -0 :warning: | yetus | 0m 2s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 1m 30s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux a0fa7c1c4f54 5.4.0-1071-aws #76~18.04.1-Ubuntu SMP Mon Mar 28 17:49:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 92cf962fee |
| Max. process+thread count | 28 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache9 commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache9 commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r952437909
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to setup the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient is perfect valid to generate
+our own private/public keypairs and set them up specifically for the HBase cluster. Especially if we don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node with `supportplaintext=True`. Restart the Master.
Review Comment:
Is it possible to implement some fallback logic at client side?
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1224090657
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 1m 35s | Docker mode activated. |
| -0 :warning: | yetus | 0m 5s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 2m 53s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux 1d4e37fbbd48 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 950ad8dd3e |
| Max. process+thread count | 29 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/2/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1227258586
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 19s | Docker mode activated. |
||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. |
||| _ master Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 18s | master passed |
| +0 :ok: | refguide | 2m 5s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 39s | branch has no errors when running spotless:check. |
||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 11s | the patch passed |
| +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. |
| +0 :ok: | refguide | 2m 8s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 40s | patch has no errors when running spotless:check. |
||| _ Other Tests _ |
| +1 :green_heart: | asflicense | 0m 9s | The patch does not generate ASF License warnings. |
| | | 11m 22s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | dupname asflicense refguide spotless |
| uname | Linux bb05d1c8ae19 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 92cf962fee |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/3/yetus-general-check/output/branch-site/book.html |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/3/yetus-general-check/output/patch-site/book.html |
| Max. process+thread count | 64 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1222666931
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 19s | Docker mode activated. |
||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. |
||| _ master Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 27s | master passed |
| +0 :ok: | refguide | 2m 33s | branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 40s | branch has no errors when running spotless:check. |
||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 2m 14s | the patch passed |
| +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. |
| +0 :ok: | refguide | 2m 7s | patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect. |
| +1 :green_heart: | spotless | 0m 39s | patch has no errors when running spotless:check. |
||| _ Other Tests _ |
| +1 :green_heart: | asflicense | 0m 13s | The patch does not generate ASF License warnings. |
| | | 12m 24s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | dupname asflicense refguide spotless |
| uname | Linux ab4a9f1bfe4e 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 00a719e76f |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/1/yetus-general-check/output/branch-site/book.html |
| refguide | https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-4717/1/yetus-general-check/output/patch-site/book.html |
| Max. process+thread count | 64 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/1/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] ss77892 commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
ss77892 commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r951768699
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
Review Comment:
I would say that we should avoid putting passwords in the configuration file at all costs. Possible the hdfs approach when you have the default password/password received through the environment variable/a special file that contains the password would be more suitable.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1224071916
@bbeaudreault Docs updated. Please re-validate the rolling upgrade steps. Hope I got it right.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1227246440
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 1m 2s | Docker mode activated. |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 1m 46s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux c0d3ccfd4478 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 92cf962fee |
| Max. process+thread count | 38 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/3/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] bbeaudreault commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
bbeaudreault commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r952642898
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
Review Comment:
Can you add a sentence "Client mode here will ensure that RegionServer's communication to HMaster is encrypted". Something like that.
---
The only situation I can think of where this will not work is with replication. In that case, a source cluster sends ReplicateWALEntry requests to RegionServers in the sink cluster. The RegionServers on the sink cluster then use normal AsyncConnection to batch put those into the Table, which will likely connect to other RegionServers in the cluster. It's possible read replicas works similarly, though I don't have expertise there yet.
So if you enable RegionServer client+server mode in one step with replication running, the replication puts will start to fail when an upgraded RegionServer tries replicating to a non-upgraded RegionServer.
We should either break this out into 2 steps, or call out that when replication is in use you need to run in 2 steps.
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart RSs in rolling restart fashion. RSs accepts both TLS/non-TLS communication.
+
+[start=4]
+. Enable secure communication on the clients.
+
+. Enable client-mode TLS on master and disable plaintext mode.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>false</value>
+</property>
+----
+
+Restart Master.
+
+[start=6]
+. Disable plaintext communication on the Region Servers by removing `supportplaintext` property. Restart RSs in rolling
+restart fashion.
+
+WARNING: Once `hbase.client.netty.tls.enabled` is enabled on the server side, the cluster will only be able to communicate
+with other clusters which have TLS enabled. For example, this would impact intra-cluster replication.
Review Comment:
Sorry I typod before, it's actually inter-cluster replication (intra meaning within)
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart RSs in rolling restart fashion. RSs accepts both TLS/non-TLS communication.
+
+[start=4]
+. Enable secure communication on the clients.
+
+. Enable client-mode TLS on master and disable plaintext mode.
Review Comment:
I think you missed a `[start=5]` here? And might be nice to add just a simple xml snippet for step 4 with the single hbase.client.netty.tls.enabled just to keep things consistent.
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart RSs in rolling restart fashion. RSs accepts both TLS/non-TLS communication.
Review Comment:
nitpick: Change second sentence to "RSs _send_ requests with TLS and _accept_ both TLS/non-TLS communication."
Just calling out the implications of each step.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1234248579
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 38s | Docker mode activated. |
| -0 :warning: | yetus | 0m 2s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 1m 24s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux 95ae502509e2 5.4.0-1071-aws #76~18.04.1-Ubuntu SMP Mon Mar 28 17:49:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 308cd729d2 |
| Max. process+thread count | 28 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache-HBase commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache-HBase commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1234249306
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 1m 2s | Docker mode activated. |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck |
||| _ Prechecks _ |
||| _ master Compile Tests _ |
||| _ Patch Compile Tests _ |
||| _ Other Tests _ |
| | | 1m 53s | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/4717 |
| Optional Tests | |
| uname | Linux 920257fdadc2 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 308cd729d2 |
| Max. process+thread count | 39 (vs. ulimit of 30000) |
| modules | C: . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4717/4/console |
| versions | git=2.17.1 maven=3.6.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1234241089
Latest commit fast forwards with 2 new features:
1. Hadoop credential API. Commited here: #4747
2. Autodetect key/truststore file types. Under review here: #4757
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] Apache9 commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
Apache9 commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r952442854
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,228 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementation. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to setup Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to setup the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient is perfect valid to generate
+our own private/public keypairs and set them up specifically for the HBase cluster. Especially if we don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node with `supportplaintext=True`. Restart the Master.
Review Comment:
Theoretically at client side it is possible. In the NettyRpcConnection implementation, before the ssl handshake finishes, we will not send any data out. So if we want to fallback to non ssl communication, we could just remove the ssl handler and set up the connection without encryption. But probably at server side we will just close the connection...
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] bbeaudreault commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
bbeaudreault commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r952642898
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
Review Comment:
Can you add a sentence "Client mode here will ensure that RegionServer's communication to HMaster is encrypted". Something like that.
---
The only situation I can think of where this will not work is with replication. In that case, a source cluster sends ReplicateWALEntry requests to RegionServers in the sink cluster. The RegionServers on the sink cluster then use normal AsyncConnection to batch put those into the Table, which will likely connect to other RegionServers in the cluster. It's possible read replicas works similarly, though I don't have expertise there yet.
So if you enable RegionServer client+server mode in one step with replication running, the replication puts will start to fail when an upgraded RegionServer tries replicating to a non-upgraded RegionServer.
We should either break this out into 2 steps, or call out that when replication is in use you need to run in 2 steps.
I know we call out inter-cluster replication below, but that's for the ReplicateWALEntry requests which go between clusters. In this case I'm concerned about the RegionServer's ability to execute Puts against other RegionServers in the cluster.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on PR #4717:
URL: https://github.com/apache/hbase/pull/4717#issuecomment-1227233664
@bbeaudreault Another round of code review fixes. Let's see how the upgrade process looks like now.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] anmolnar commented on a diff in pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
anmolnar commented on code in PR #4717:
URL: https://github.com/apache/hbase/pull/4717#discussion_r954937799
##########
src/main/asciidoc/_chapters/security.adoc:
##########
@@ -675,6 +675,290 @@ For more information about ACLs, please see the <<hbase.accesscontrol.configurat
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPNEGO HTTP authentication.
This is future work.
+== Transport Level Security (TLS) in HBase RPC communication
+
+Since version `2.6.0` HBase supports TLS encryption in server-client and Master-RegionServer communication.
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[Transport Layer Security (TLS)] is a standard
+cryptographic protocol designed to provide communications security over a computer network. HBase TLS implementation
+works exactly how secure websites are accessed via *https* prefix in a web browser: once established all communication
+on the channel will be securely hidden from malicious access.
+
+The encryption works at the transport level which means it's independent of the configured authentication method. Secure
+client access mentioned in the previous section requires Kerberos to be configured and used in HBase authentication, while
+TLS can be configured with any other SASL mechanism or even with simple client access methods, effectively preventing
+attackers from eavesdropping the communication. No Kerberos KDC or other complicated infrastructure required.
+
+HBase TLS is based on the Netty library therefore it only works with Netty client and server RPC implementations. Netty's
+powerful SSL implementation is a great foundation for highly secure and performant communication providing the latest and
+greatest cryptographic solution at all times.
+
+Since Region Servers effectively work as clients from Master's perspective, TLS supports encrypted communication
+between cluster members too.
+
+=== Server side configuration
+
+We need to set up Java key store for the server. Key store is the list of private keys that a server can use to configure TLS
+encryption. See link:https://en.wikipedia.org/wiki/Transport_Layer_Security/[TLS wikipedia page]
+for further details of the protocol. Add the following configuration to `hbase-site.xml` on Master, Region Servers and HBase
+clients:
+
+[source,xml]
+----
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.location</name>
+ <value>/path/to/keystore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.keystore.password</name>
+ <value>keyStor3pa$$w0rd</value>
+</property>
+----
+
+The supported store types are based on the registered security providers. If not specified, JKS will be used by default.
+
+=== Client side configuration
+
+We need to configure trust store for the client. Trust store contains the list of certificates that the client should trust
+when doing the handshake with the server. Add the following to `hbase-site.xml`.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.type</name>
+ <value>JKS</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.location</name>
+ <value>/path/to/truststore.jks</value>
+</property>
+<property>
+ <name>hbase.rpc.tls.truststore.password</name>
+ <value>trustStor3pa$$w0rd</value>
+</property>
+----
+
+However, specifying a trust store is not always required. Standard JDK implementations are shipped with a standard list
+of trusted certificates (the certificates of Certificate Authorities) and if your private key is provided by one of them,
+you don't need to configure your clients to trust it. Similarly to an internet browser, you don't need to set up the
+certificates of every single website you're planning to visit. Later in this documentation we'll walk through the steps of
+creating self-signed certificates which requires a trust store setup.
+
+You can check the list of public certificate authorities shipped with your JDK implementation:
+
+----
+keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -list
+----
+
+Password is empty by default.
+
+=== Creating self-signed certificates
+
+While obtaining globally trusted certificates from Certificate Authorities is convenient, it's perfectly valid to generate
+your own private/public keypairs and set them up specifically for the HBase cluster. Especially if you don't want to enable
+public access to the cluster, paying money for a certificate doesn't make sense.
+
+Follow the following steps to generate self-signed certificates.
+
+. Create SSL key store JKS to store local credentials
+
+Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is
+associated with, otherwise hostname verification won't work.
+
+----
+keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
+----
+
+At the end of this operation you'll have as many key store files as many servers you have in your cluster. Each cluster member
+will have its own key store.
+
+[start=2]
+. Extract the signed public key (certificate) from each key store
+
+----
+keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
+----
+
+[start=3]
+. Create SSL trust store JKS containing certificates for the clients
+
+The same truststore (storing all accepted certs) should be shared on participants of the cluster. You need to use different
+aliases to store multiple certificates in the same truststore. Name of the aliases doesn't matter.
+
+----
+keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
+----
+
+=== Upgrading existing non-TLS cluster with no downtime
+
+Here are the steps needed to upgrade an already running HBase cluster to TLS without downtime by taking advantage of
+port unification functionality. There's a property on server side called `hbase.server.netty.tls.supportplaintext`
+which makes possible to accept TLS and plaintext connections on the same socket port.
+
+. Create the necessary key stores and trust stores for all server participants as described in the previous section.
+
+. Enable secure communication on the Master node in _server-only_ mode with plaintext support.
+
+[source,xml]
+----
+<property>
+ <name>hbase.client.netty.tls.enabled</name>
+ <value>false</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.enabled</name>
+ <value>true</value>
+</property>
+<property>
+ <name>hbase.server.netty.tls.supportplaintext</name>
+ <value>true</value>
+</property>
+...keystore / truststore setup ...
+----
+
+Restart the Master. Master now accepts both TLS/non-TLS connections and works with non-TLS in client mode.
+
+[start=3]
+. Enable secure communication on the Region Servers in both _server and client_ mode with plaintext support.
Review Comment:
Fair point. I added a summary of your comments into a Warning block.
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [hbase] bbeaudreault merged pull request #4717: HBASE-27226 Document native TLS support in Netty RPC
Posted by GitBox <gi...@apache.org>.
bbeaudreault merged PR #4717:
URL: https://github.com/apache/hbase/pull/4717
--
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: issues-unsubscribe@hbase.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org