Security Advisory: [2020 October] Potential Privilege Escalation in Confluent Platform 5.4 and 5.5

Executive Summary

As of Confluent Platform (CP) 5.4, customers can use mechanisms such as Role-Based Access Control (RBAC) and Access Control Lists (ACLs) to restrict user access to resources within the platform. Customers can manage these access policies centrally via the Metadata Service (MDS) and these policies are intended to be enforced throughout the platform. However, if Confluent Control Center (C3) or ksqlDB components are misconfigured, a user with limited privileges can experience elevated permissions via C3 or ksqlDB. For example, a user may not have any permissions configured in MDS that would enable to create Kafka topics, but nonetheless may be able to create topics via the C3 UI. Furthermore, for customers who use the Confluent Operator to deploy and manage the platform, and have enabled RBAC, this misconfiguration will be present for C3.

• Affected Confluent Platform versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0, 5.5.1
• Fixed Confluent Platform versions: 5.4.3, 5.5.2

How to Determine if you are Affected

• Customers who are using Confluent Operator 1.5.0 (released with CP 5.5.0) or 1.5.1 (released with CP 5.5.1) to deploy C3 and have RBAC enabled are impacted by this misconfiguration. Specifically, Operator will configure C3 to connect to Kafka via mutual TLS (mTLS) authentication. In this case, end user principals are not propagated to MDS and thus RBAC is not properly enforced, leading to privilege escalations.
• Customers who are manually configuring and deploying C3 or ksqlDB versions 5.4.0, 5.4.1, 5.4.2, 5.5.0 or 5.5.1 and who have enabled RBAC are impacted by this potential misconfiguration. Specifically, C3 and ksqlDB are considered to be misconfigured in this scenario if they are not configured to connect to Kafka via its TOKEN listener, which uses a SASL OAUTHBEARER authentication mechanism. If you have configured C3 or ksqlDB to connect to Kafka via the TOKEN listener, then you are not impacted, and require no further action.

Actions Required if you are Affected

Automated Deployment

Customers who are managing C3 via Confluent Operator and have RBAC enabled should download the Confluent Operator 1.5.2 bundle for CP 5.5.2, and update all Operator-managed C3 deployments using this bundle.

The typical workflow for updating a C3 deployment is to run the following Helm command:

$ helm upgrade --install controlcenter \
    <path-to-extracted-bundle> \
    -f ${VALUES_FILE} \
    --set controlcenter.enabled=true

Customers should follow the same workflow, but ensure that <path-to-extracted-bundle> is the path to the downloaded and extracted Confluent Operator 1.5.2 bundle for CP 5.5.2, rather than the bundle that was used for any previous installations or updates; the ${VALUES_FILE} should remain the same as what you used before.

Note that this process will update Control Center to patch version 5.5.2. If you are using CP 5.5.0 or CP 5.5.1, even if you are not impacted by this privilege escalation (e.g. if you have not enabled RBAC), Confluent strongly recommends applying this update to your platform as CP 5.5.2 contains various bug fixes.

Manual Deployment

Customers who are manually configuring and deploying C3 or ksqlDB and have RBAC enabled should ensure that these components are configured to connect to Kafka via its TOKEN listener. Please refer to Confluent documentation:

• Configure ksqlDB Server for RBAC
• Set RBAC configuration options in the Control Center properties file

In addition, customers currently on CP 5.4.0, 5.4.1, or 5.4.2 are strongly advised to update to CP 5.4.3; customers currently on CP 5.5.0 or 5.5.1 are strongly advised to update to CP 5.5.2. In addition to several bug fixes, these releases will include updates to C3 and ksqlDB that will prevent misconfigurations. If misconfigured by the user, C3 and ksqlDB will fail to start up and will advise the user to reconfigure securely.

Additional Details

CP enables customers to manage user access to the platform. For example, in a given organization, some users should only have access to create certain Kafka topics or read messages from certain Kafka topics; Confluent Platform allows customers to configure Role-Based Access Control (RBAC) and Access Control Lists (ACLs) to limit such users to specific actions on specific resources. These access policies can be managed centrally across multiple Kafka clusters and other CP components, via the Metadata Service (MDS). Furthermore, user access to resources is intended to be limited regardless of how the user attempts to interact with the resource. For example, if a user does not have access to read data from a particular topic, then the user should be prevented from reading from that topic via a CLI, via the Confluent Control Center (C3) UI, or by creating a ksqlDB query that reads from the topic.

In order for C3 and ksqlDB to ensure that RBAC and ACL policies are correctly enforced, these components must be configured to connect to the underlying Kafka cluster in a particular way, namely by connecting to the conventionally-named TOKEN listener on the Kafka brokers. It is via this authentication mechanism, and only via this mechanism, that the end user principal can be propagated to Kafka. When an end user attempts to inspects a Kafka topic, for example, via C3, C3 authenticates with Kafka and attempts to get the relevant data from the topic. C3 authenticates with Kafka as a service principal which typically has fairly elevated permissions. C3 also includes metadata about the end user principal when connecting to Kafka, but it is only when connecting to the TOKEN listener that Kafka authorizes C3’s attempt to get the topic data based on the permissions of the end user rather than the C3 service principal.

When RBAC is enabled, C3 prevents customers from configuring C3 to connect to Kafka via a listener with a SASL authentication mechanism other than OAUTHBEARER (i.e. the TOKEN listener). However C3 does not prevent customers from configuring C3 to connect to Kafka via a listener with mTLS authentication. Thus, it is possible for the customer to intend to implement RBAC across the platform, but configure C3 to connect to Kafka in such a way that RBAC is not properly enforced for end users using C3. This same issue of failing to prevent customers from configuring ksqlDB to connect to Kafka via the TOKEN listener when RBAC is enabled similarly applies to ksqlDB as it does to C3.

With CP 5.4.3 and CP 5.5.2, C3 and ksqlDB will actively prevent customers from misconfiguring them. In the existing CP 5.4.x and 5.5.x (prior to CP 5.4.3 and CP 5.5.2) releases, neither C3 nor ksqlDB prevent the customer from misconfiguring them, however customers are not prevented from correctly configuring these components either, and Confluent’s documentation intends to guide customers to the correct, secure configuration.

Confluent Operator is a more opinionated component for configuring and managing the full lifecycle of Confluent Platform, and in particular facilitates the configuration of the other components such as ksqlDB and C3, requiring less manual configuration on the part of the customer. When RBAC is enabled, Operator configures ksqlDB correctly, and the user is not exposed to the misconfiguration risk when manually configuring and installing. However, the initial support for RBAC via the Operator did misconfigure C3. In particular, it configures C3 to connect to Kafka via mTLS, and this is not something customers can change or adjust manually. This bug is addressed in the Operator bundle for CP 5.5.2. Customers will simply need to update their C3 deployments using the new Operator bundles.