From commits-return-12238-archive-asf-public=cust-asf.ponee.io@pulsar.incubator.apache.org Thu Aug 2 10:05:16 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id EE62A180629 for ; Thu, 2 Aug 2018 10:05:15 +0200 (CEST) Received: (qmail 665 invoked by uid 500); 2 Aug 2018 08:05:15 -0000 Mailing-List: contact commits-help@pulsar.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@pulsar.incubator.apache.org Delivered-To: mailing list commits@pulsar.incubator.apache.org Received: (qmail 650 invoked by uid 99); 2 Aug 2018 08:05:15 -0000 Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2018 08:05:15 +0000 From: GitBox To: commits@pulsar.apache.org Subject: [GitHub] sijie commented on a change in pull request #2286: [website] cherry-pick "Rework TLS docs to separate concerns" to new website Message-ID: <153319711454.4097.6774492536835683738.gitbox@gitbox.apache.org> Date: Thu, 02 Aug 2018 08:05:14 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit sijie commented on a change in pull request #2286: [website] cherry-pick "Rework TLS docs to separate concerns" to new website URL: https://github.com/apache/incubator-pulsar/pull/2286#discussion_r207134727 ########## File path: site2/docs/security-tls-transport.md ########## @@ -0,0 +1,196 @@ +--- +id: security-tls-transport +title: Transport Encryption using TLS +sidebar_label: Transport Encryption using TLS +--- + +## TLS Overview + +By default, Apache Pulsar clients communicate with the Apache Pulsar service in plain text, which means that all data is sent in the clear. TLS can be used to encrypt this traffic so that it cannot be snooped by a man-in-the-middle attacker. + +TLS can be configured for both encryption and authentication. You may configure just TLS transport encryption, which is covered in this guide. TLS authentication is covered [elsewhere](security-tls-authentication.md). Alternatively, you can use [another authentication mechanism](security-athenz.md) on top of TLS transport encryption. + +> Note that enabling TLS may have a performance impact due to encryption overhead. + +## TLS concepts + +TLS is a form of [public key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography). Encryption is performed using key pairs consisting of a public key and a private key. Messages are encrypted with the public key and can be decrypted with the private key. + +To use TLS transport encryption, you need two kinds of key pairs, **server key pairs** and a **certificate authority**. + +A third kind of key pair, **client key pairs**, are used for [client authentication](security-tls-authentication.md). + +The **certificate authority** private key should be stored in a very secure location (a fully encrypted, disconnected, air gapped computer). The certificate authority public key, the **trust cert**, can be freely shared. + +For both client and server key pairs, the administrator first generates a private key and a certificate request. Then the certificate authority private key is used to sign the certificate request, generating a certificate. This certificate is the public key for the server/client key pair. + +For TLS transport encryption, the clients can use the **trust cert** to verify that the server they are talking to has a key pair that was signed by the certificate authority. A man-in-the-middle attacker would not have access to the certificate authority, so they couldn't create a server with such a key pair. + +For TLS authentication, the server uses the **trust cert** to verify that the client has a key pair that was signed by the certificate authority. The Common Name of the **client cert** is then used as the client's role token (see [Overview](security-overview.md)). + +## Creating TLS Certificates + +Creating TLS certificates for Pulsar involves creating a [certificate authority](#certificate-authority) (CA), [server certificate](#server-certificate), and [client certificate](#client-certificate). + +The following guide is an abridged guide to setting up a certificate authority. For a more detailed guide, there are plenty of resource on the internet. We recommend the [this guide](https://jamielinux.com/docs/openssl-certificate-authority/index.html). + +### Certificate authority + +The first step is to create the certificate for the CA. The CA will be used to sign both the broker and client certificates, in order to ensure that each party will trust the others. The CA should be stored in a very secure location (ideally completely disconnected from networks, air gapped, and fully encrypted). + +Create a directory for your CA, and place [this openssl configuration file](https://github.com/apache/incubator-pulsar/tree/master/site2/website/static/examples/openssl.cnf) in the directory. You may want to modify the default answers for company name and department in the configuration file. Export the location of the CA directory to the environment variable, CA_HOME. The configuration file uses this environment variable to find the rest of the files and directories needed for the CA. + +```bash +$ mkdir my-ca +$ cd my-ca +$ wget {{ "/docs/latest/security/openssl.cnf" | absolute_url }} Review comment: fixed ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: users@infra.apache.org With regards, Apache Git Services