Security Best Practices¶
Lenses is built with security as a requirement. Therefore, in this section we provide some advices 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 to any security minded application deployment.
When it comes to setting up Lenses, you can follow this advices:
- 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
- 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 plain text connections will be allowed.
- If the proxy server lies on the same machine as Lenses, then set Lenses to bind on the local interface (
- Do not run Lenses as the root user.
- Enable and configure SELinux (if supported) to further lock down and protect
the Lenses process.
- Other OS level mitigations may need certain workarounds. For example, if
you mount the
noexeccheck JNI libraries and Code Execution,
- Other OS level mitigations may need certain workarounds. For example, if you mount the
- 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 be readable by the Lenses process only — and optionally the root user.
- Do not expose Lenses to the Internet.
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.
Although when utilizing Kafka ACLs the common advice is to give Lenses super.user status, that is the same rights as the brokers, you may want to restrict the Kafka topics that 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 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 notice 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 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.
One of the key functions that Lenses provides is a 360 degree view of your streaming data, making it 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.