Business Fortune
Altinity is built on three discoveries that will fundamentally alter how companies extract value from data. Quick access to massive amounts of data can open a world of economic value. The most effective way to create and swiftly release user-friendly database solutions is through inclusive open source communities. Of all the data management products available on the market, ClickHouse SQL Data Warehouse provides the highest performance, scalability, and flexibility.
San Carlos, CA, was the starting point of the Altinity adventure. The CTO of Altinity, Alexander Zaitsev, discovered a basic issue with analytics for ad networks: the amount of data needed to determine where to position ads is growing considerably faster than revenue for the company. The only database that could grow profitably was ClickHouse, outperforming far more established analytical tools. However, it was by no means enterprise quality.
Alexander partnered with prominent open source database specialists Peter Zaitsev and Vadim Tkachenko, the founders of Percona. Similar to Alexander, Peter and Vadim recognized ClickHouse's potential as "MySQL for analytics." Together, they established a business to improve ClickHouse and offer advice to enterprise users. The company was founded in 2017, and Mindaugas Zukas, an experienced manager, joined as the fourth founder to lead it.
Alexander also hounded his friend Robert Hodges about the amazing new database he was working on. As CEO, Robert joined the group in 2019. Like the others, he recognized the potential to establish a distinctive database offering that would enable new markets and data applications. To realize this vision, Altinity is assembling a group of collaborators who share similar values. A crucial factor in contemporary software systems is security. This is especially true for programs like database software that handle sensitive data. A wide range of tools are available from ClickHouse to enhance security. The user, network, and storage categories can be used to categorize these security aspects.
Increasing ClickHouse security at the user level entails implementing security best practices and imposing limitations on an individual basis. Quotas, LDAP remote authentication, resource constraints (i.e., limiting which tables are available by which users), and network restrictions are a few of the capabilities provided by ClickHouse. All of these are covered in further detail in Altinity's User Hardening guide.
ClickHouse has strong yet often unclear user-level network access controls. This blog post delves further into their operation and explains how to use them to safeguard ClickHouse data.
What is User Level Network Security on ClickHouse?
Only specific hosts can be allowed to establish connections using the ClickHouse user-level network security toolkit. Use of the IP, host, like pattern, or host_regexp directives can do this. The other three methods rely on reverse DNS resolution, whereas the IP directive does this by simply comparing the client IP address with the permitted IP. The four distinct ways ClickHouse allows you to limit access to particular hosts are displayed in the graphic below. The IP directive enables the specification of a list of permitted IP addresses for a certain user, as was previously indicated. It is a straightforward method that will cover common situations in which the client's IP address is fixed.
Regretfully, not all ClickHouse users have a static IP address. Cloud apps can change IP addresses as they move across availability zones. When pods restart, ClickHouse clients on Kubernetes may experience IP address changes. Approaches based on hostnames and reverse DNS resolution make more sense in these situations.
Similar to the IP directive, but for hostnames, is the host directive. For each user, ClickHouse allows you to specify a list of permitted hostnames, and it will ensure that only those hostnames are allowed to connect. Hostnames are more likely to stay constant than IP addresses, which is the primary advantage of this method over the IP one.
Final Remarks
Limiting the hosts that can make connections is only one of the ways that ClickHouse security can be made better at the user level. ClickHouse has four alternative parameters to accomplish this: IP, host, like pattern, and host_regexp. Depending on the situation, each of these options should be used, as they each have advantages and disadvantages.
Simpler methods like IP and host handle the most common cases, but they are not very scalable if IPs are not stable or if the list of permitted hostnames is expected to change over time. The like pattern and host_regexp fit the bill better in these situations, provided that the hostnames exhibit a predictable pattern.
When it comes to hostname matching, patterns and host_regexp both offer a very versatile solution. The latter enabling more fine-grained filtering, and the former being more straightforward. Generally speaking, users should, if at all possible, default to the like pattern. If the like pattern is too complex or does not fully meet the use case, host_regexp should be adopted.
One needs to consider the possibility of an increase in latency caused by DNS queries while implementing one of the strategies that rely on reverse DNS resolution. ClickHouse will cache DNS queries by default, reducing any negative impacts.
Finally, but just as importantly, Altinity's addition of multiple hostname support not only conforms with network layer standards, but it also expands the use cases of this capability for a range of scenarios. One of them is the ClickHouse Kubernetes clusters managed by Altinity ClickHouse Operator.
Robert Hodges, CEO
