Security Best Practices

Lenses is built with security as a requirement. Therefore, in this section, we provide some advice and best practices that you can follow to make your Lenses installation more secure. A lot of these ideas are not Lenses specific but can be applied by any security-minded application deployment.

Lenses Setup

When it comes to setting up Lenses you can follow this advice:

  • Setup Lenses on its own machine (physical server or virtual machine).
  • Setup a proxy in front of Lenses (like Nginx or Apache) to provide SSL termination or setup Lenses to use TLS (see Enabling TLS).
    • If the proxy server lies on the same machine as Lenses, then set Lenses to bind on the local interface (lenses.ip=127.0.0.1) so no plaintext connections will be allowed.
  • Do not run Lenses as the root user.
  • Enable and configure SELinux (if supported) to lock down and protect further the Lenses process.
  • Update Lenses often, especially if the changelog mentions security fixes.
  • The security configuration file should only be readable by the Lenses process and optionally the root user.
  • Any file used for authentication (keystores and keytabs) should only be readable by the Lenses process —and optionally the root user.
  • Do not expose Lenses to the internet.

Kafka Access

Lenses is a Kafka client. Make sure your connection to the brokers is secured. The most secure schemes for Kafka are SSL and SASL_SSL.

If you utilize Kafka ACLs, although the common advice is to give Lenses super.user status —that is same rights as the brokers—, you may want to restrict which topics Lenses is allowed to read and write. For certain topics, access is required, please check the ACLs for Lenses and system topics section.

Lenses, also, utilizes the brokers’ JMX data to display metrics and provide better monitoring. Whilst it remains fully functional without access to JMX, it is still suggested to setup this connection. When security is a top priority, you can password protect the JMX access and provide Lenses with a read-only account. Alternatively, you can use the Jolokia monitoring agent, again with password protection and read-only access. Both JMX and Jolokia may be served over a TLS connection for transport-encryption.

3rd Party Services Access

Lenses may need access to third-party software, like Zookeeper, Schema Registry, Kafka Connect and Kubernetes. Verify that access to each service is indeed needed before granting it. For example, a connection to Zookeeper is only required if you wish to manage quotas via Lenses. In such a case, Lenses can use Kerberos to connect to Zookeeper. Schema Registry access is required if you work with AVRO. Lenses can use basic authentication to connect to Confluent’s Schema Registry, or Kerberos to connect to HortonWorks Schema Registry. If you have one or more Kafka Connect clusters, Lenses will help you manage and monitor your connectors. Basic authentication to Connect’s REST endpoints is supported. Please note that basic authentication should always happen over SSL. Kubernetes can be used to scale SQL processing, by launching processors in it. The service account provided to Lenses may be restricted via Kubernetes RBAC to certain namespaces. Lenses need to be able to create, manage and destroy deployments and secrets.

When it comes to JMX access, you can avoid it altogether for the 3rd party services that do support it. The most noticeable effect is that metrics for connectors will be absent in such a case. You can setup JMX access to the Connect workers and, as in the case of the brokers, protect it with a password and a read-only account, or use the Jolokia agent. Both JMX and Jolokia may be served over a TLS connection for transport-encryption.

User Management

One of the key functions that Lenses provides is a 360-degree view of your streaming data, making them accessible to more people within your organization. Opening access often brings the challenge to restrict certain data streams to groups of people. Lenses incorporates two tools to help with this task. The group-based security allows you to control the topics each user is allowed to access and the level of access they command, such as list topics, view data or even write into a topic. The Data Policies functionality allows you to set per-field obfuscation policies, so you can protect sensitive fields whilst still allowing access to the topic.