Pulsar supports a pluggable authentication mechanism that Pulsar clients can use to authenticate with {% popover brokers %}. Pulsar can also be configured to support multiple authentication sources.
In Pulsar, a role is a string, like admin or app1, that can represent a single client or multiple clients. Roles are used to control permission for clients to produce or consume from certain topics, administer the configuration for {% popover properties %}, and more.
The purpose of the authentication provider is to establish the identity of the client and then assign that client a role token. This role token is then used to determine what the client is authorized to do.
Out of the box, Pulsar supports two authentication providers:
In addition to providing connection encryption between Pulsar clients and {% popover brokers %}, Transport Layer Security (TLS) can be used to identify clients through a certificate signed by a trusted certificate authority.
Creating TLS certificates for Pulsar involves creating a certificate authority (CA), broker certificate, and client certificate.
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.
$ CA.pl -newca
$ /System/Library/OpenSSL/misc/CA.pl -newca
After answering the question prompts, this will store CA-related files in the ./demoCA directory. Within that directory:
demoCA/cacert.pem is the public certificate. It is meant to be distributed to all parties involved.demoCA/private/cakey.pem is the private key. This is only needed when signing a new certificate for either broker or clients and it must be safely guarded.Once a CA certificate has been created, you can create certificate requests and sign them with the CA.
The following commands will ask you a few questions and then create the certificates. When asked for the common name, you need to match the hostname of the broker. You could also use a wildcard to match a group of broker hostnames, for example *.broker.usw.example.com. This ensures that the same certificate can be reused on multiple machines.
$ openssl req \ -newkey rsa:2048 \ -sha256 \ -nodes \ -out broker-cert.csr \ -outform PEM
Convert the key to PKCS 8 format:
$ openssl pkcs8 \ -topk8 \ -inform PEM \ -outform PEM \ -in privkey.pem \ -out broker-key.pem \ -nocrypt
This will create two broker certificate files named broker-cert.csr and broker-key.pem. Now you can create the signed certificate:
$ openssl ca \ -out broker-cert.pem \ -infiles broker-cert.csr
At this point, you should have a broker-cert.pem and broker-key.pem file. These will be needed for the broker.
To create a client certificate, repeat the steps in the previous section, but did create client-cert.pem and client-key.pem files instead.
For the client common name, you need to use a string that you intend to use as the role token for this client, though it doesn't need to match the client hostname.
To configure a Pulsar {% popover broker %} to use TLS authentication, you'll need to make some changes to the broker.conf configuration file, which is located in the conf directory of your Pulsar installation.
Add these values to the configuration file (substituting the appropriate certificate paths where necessary):
# Enable TLS and point the broker to the right certs tlsEnabled=true tlsCertificateFilePath=/path/to/broker-cert.pem tlsKeyFilePath=/path/to/broker-key.pem tlsTrustCertsFilePath=/path/to/cacert.pem # Enable the TLS auth provider authenticationEnabled=true authorizationEnabled=true authenticationProviders=org.apache.pulsar.broker.authentication.AuthenticationProviderTls
{% include message.html id=“broker_conf_doc” %}
The {% popover discovery %} service used by Pulsar brokers needs to redirect all HTTPS requests, which means that it needs to be trusted by the client as well. Add this configuration in conf/discovery.conf in your Pulsar installation:
tlsEnabled=true tlsCertificateFilePath=/path/to/broker-cert.pem tlsKeyFilePath=/path/to/broker-key.pem
For more information on Pulsar client authentication using TLS, see the following language-specific docs:
Command-line tools like pulsar-admin, pulsar-perf, and pulsar-client use the conf/client.conf config file in a Pulsar installation.
You‘ll need to add the following authentication parameters to that file to use TLS with Pulsar’s CLI tools:
serviceUrl=https://broker.example.com:8443/ authPlugin=org.apache.pulsar.client.impl.auth.AuthenticationTls authParams=tlsCertFile:/path/to/client-cert.pem,tlsKeyFile:/path/to/client-key.pem useTls=true tlsAllowInsecureConnection=false tlsTrustCertsFilePath=/path/to/cacert.pem
Athenz is a role-based authentication/authorization system. In Pulsar, Athenz role tokens (aka z-tokens) can be used to establish the identify of the client.
In a decentralized Athenz system there is both an authoriZation Management System (ZMS) server and an authoriZation Token System (ZTS) server.
To begin, you need to set up Athenz service access control. You should create domains for the provider (which provides some resources to other services with some authentication/authorization policies) and the tenant (which is provisioned to access some resources in a provider). In this case, the provider corresponds to the Pulsar service itself and the tenant corresponds to each application using Pulsar (typically, a {% popover property %} in Pulsar).
On the {% popover tenant %} side, you need to:
shoppingsome_app, on the domain with the public keyNote that the private key generated in step 2 needs to be specified when the Pulsar client connects to the {% popover broker %} (see client configuration examples for Java and C++).
For more specific steps involving the Athenz UI, please refer to this doc.
On the provider side, you need to:
pulsarNote that in step 2 any action and resource can be specified since they are not used on Pulsar. In other words, Pulsar uses the Athenz role token only for authentication, not for authorization.
For more specific steps involving UI, please refer to this doc.
{% include message.html id=“tls_role_tokens” %}
In the conf/broker.conf configuration file in your Pulsar installation, you need to provide the class name of the Athenz authentication provider as well as a comma-separated list of provider domain names.
# Add the Athenz auth provider authenticationEnabled=true authorizationEnabled=true authenticationProviders=org.apache.pulsar.broker.authentication.AuthenticationProviderAthenz athenzDomainNames=pulsar # Enable TLS tlsEnabled=true tlsCertificateFilePath=/path/to/broker-cert.pem tlsKeyFilePath=/path/to/broker-key.pem
{% include message.html id=“broker_conf_doc” %}
For more information on Pulsar client authentication using Athenz, see the following language-specific docs:
Command-line tools like pulsar-admin, pulsar-perf, and pulsar-client use the conf/client.conf config file in a Pulsar installation.
You’ll need to add the following authentication parameters to that file to use Athenz with Pulsar’s CLI tools:
# URL for the broker serviceUrl=https://broker.example.com:8443/ # Set Athenz auth plugin and its parameters authPlugin=org.apache.pulsar.client.impl.auth.AuthenticationAthenz authParams=tenantDomain:shopping,tenantService:some_app,providerDomain:pulsar,privateKeyPath:/path/to/private.pem,keyId:v1 # Enable TLS useTls=true tlsAllowInsecureConnection=false tlsTrustCertsFilePath=/path/to/cacert.pem
In Pulsar, the authentication provider is charged with properly identifying clients and associating them with role tokens. Authorization is the process that determines what clients are able to do.
Authorization in Pulsar is managed at the {% popover property %} level, which means that you can have multiple authorization schemes active in a single Pulsar instance. You could, for example, create a shopping property that has one set of roles and applies to a shopping application used by your company, while an inventory property would be used only by an inventory application.
{% include message.html id=“properties_multiple_clusters” %}
A Pulsar {% popover property %} identifies a {% popover tenant %} and is typically provisioned by Pulsar {% popover instance %} administrators or by some kind of self-service portal.
Properties are managed using the pulsar-admin tool. Here's an example property creation command:
$ bin/pulsar-admin properties create my-property \ --admin-roles my-admin-role \ --allowed-clusters us-west,us-east
This command will create a new property my-property that will be allowed to use the clusters us-west and us-east.
A client that successfully identified itself as having the role my-admin-role would then be allowed to perform all administrative tasks on this property.
The structure of topic names in Pulsar reflects the hierarchy between properties, clusters, and namespaces:
{% include topic.html p=“property” c=“cluster” n=“namespace” t=“topic” %}
{% include explanations/permissions.md %}
In Pulsar you can assign certain roles to be superusers of the system. A superuser is allowed to perform all administrative tasks on all properties and namespaces, as well as to publish and subscribe to all topics.
Superusers are configured in the broker configuration file in conf/broker.conf configuration file, using the superUserRoles parameter:
superUserRoles=my-super-user-1,my-super-user-2
{% include message.html id=“broker_conf_doc” %}
Typically, superuser roles are used for administrators and clients but also for broker-to-broker authorization. When using geo-replication, every broker needs to be able to publish to other clusters' topics.
String authPluginClassName = "com.org.MyAuthPluginClass"; String authParams = "param1:value1"; boolean useTls = false; boolean tlsAllowInsecureConnection = false; String tlsTrustCertsFilePath = null; ClientConfiguration config = new ClientConfiguration(); config.setAuthentication(authPluginClassName, authParams); config.setUseTls(useTls); config.setTlsAllowInsecureConnection(tlsAllowInsecureConnection); config.setTlsTrustCertsFilePath(tlsTrustCertsFilePath); PulsarAdmin admin = new PulsarAdmin(url, config);
To use TLS:
String authPluginClassName = "com.org.MyAuthPluginClass"; String authParams = "param1:value1"; boolean useTls = false; boolean tlsAllowInsecureConnection = false; String tlsTrustCertsFilePath = null; ClientConfiguration config = new ClientConfiguration(); config.setAuthentication(authPluginClassName, authParams); config.setUseTls(useTls); config.setTlsAllowInsecureConnection(tlsAllowInsecureConnection); config.setTlsTrustCertsFilePath(tlsTrustCertsFilePath); PulsarAdmin admin = new PulsarAdmin(url, config);