A team that owns its Kafka topics can consume them, browse them and change their config in Console without asking anyone. Flink SQL on those same topics has meant something else: a Confluent service account, an API key, and a credential that usually reads more than the team owns.
Conduktor Console 1.47 adds a Flink SQL workbench for Confluent Cloud, in preview. Teams explore, join and transform the topics they own from Console, on their own. Flink reuses their existing topic permissions. The platform team grants nothing new and gives up no control.
More Kafka Work Is Moving Into Stream Processors
Joins, aggregations and transformations used to live in hand-written consumer applications. More of that work now runs in a stream processor, whether that's Kafka Streams, ksqlDB or Flink, and on Confluent Cloud that increasingly means Flink SQL: a team reads from several topics, transforms the stream, and writes the result back to a new one. SQL over a stream also lets people who never wrote a consumer ask questions of the data.
Wherever the processing runs, the access model has to follow it. Topic ACLs and Console permissions decide who may consume payments. If a SELECT from payments doesn't consult them, you have two access models, and the second one is usually a shared service account.
Topics as tables. Flink SQL and Confluent Cloud name the same tree differently. An environment is a catalog, a Kafka cluster is a database, a topic is a table, and the Schema Registry subject supplies the columns. A compute pool is Confluent's serverless Flink capacity in one region, and it's the resource you grant Flink access on. A fully qualified table name reads environment, cluster, topic.
Least Privilege, in the Same Console
Console's governance model already gives each team the smallest set of permissions it needs on its own resources. Flink SQL now sits inside that model rather than beside it. Two grants cover it:
- Run Flink on a compute pool, or on every pool in an environment. This is the only new permission.
- The topic permissions the team already has. Read lets them query a topic. Write, create and delete let them build on it.
The engineer below belongs to a group with read on the sample_data topic and Run Flink on one pool. Flink sits in the Console sidebar next to Topics and Brokers, and the catalog is the same cluster and the same topics the team already browses, filtered to what they may read. One database, one table. Expanding it lists the columns from Schema Registry, and results, statement status, stop and delete share the screen with the editor.
Query one: where the orders are going
SELECT address.state AS state,
COUNT(*) AS orders,
ROUND(SUM(orderunits), 1) AS units
FROM `demo`.`rubberducks-demo`.`sample_data`
GROUP BY address.state;Streaming mode. One row per state, and the counts change as new orders arrive.
The statement runs on the pool and results stream into the table. Snapshot mode gives a bounded read you can export to CSV. They already had read on the topic, and that was enough to run the query. No one else was involved.
Query two: keep the result as a new topic
CREATE TABLE `demo`.`rubberducks-demo`.`large_orders` AS
SELECT orderid, itemid, orderunits, address.state AS state
FROM `demo`.`rubberducks-demo`.`sample_data`
WHERE orderunits > 8;On Confluent Cloud this creates a Kafka topic and starts writing to it. Console refuses it. The team can read sample_data but has neither create nor write on large_orders, and the error says so.
If the team should be able to build derived topics, its owner grants create and write on a prefix, the same way they would for a producer. Flink doesn't get its own role or identity.
How the Permission Check Works
Handing teams a SQL editor is only safe if the editor can't do more than the team could already do. Console enforces that by authorizing the statement itself, not the person's session.
Every statement goes to Confluent Cloud through one credential that an admin registers once. Confluent authorizes that credential and never sees the person behind it, so Console enforces its own security boundary. Before the statement leaves Console, Console parses the SQL with Flink's own parser, extracts each topic it touches and the action on it, and checks each against the Kafka topic permission on the Console cluster that backs the database:
| Statement | Topic permission required |
|---|---|
SELECT ... FROM t | Read on t |
INSERT INTO t ... | Write on t |
CREATE TABLE t ... | Create on t, plus write if it's populated |
DROP TABLE t | Delete on t. On Confluent Cloud this deletes the topic and its data. |
Confluent's own RBAC covers this for teams that live entirely in Confluent Cloud, where every engineer has a Confluent identity and interactive statements run as the person. Teams that run Confluent alongside MSK or self-managed clusters keep their access model in SSO groups and a governance layer that spans all of them, and for them Flink had meant a second permission system to keep in sync. Console lets Flink inherit the one they already have.
What the Platform Team Does
Register the Confluent organization once, with a Cloud API key created at Global scope, then grant Run Flink to a group on one compute pool or on every pool in an environment. Topic permissions stay as they are.
One key, one grant per group. New members join the group in your identity provider. Nobody creates a Confluent identity for each engineer or rotates a service account key for each team.
Scope of the Preview
- Confluent Cloud Flink, from Console 1.47, behind the Flink entry in the sidebar.
- Run, watch, export, stop and delete statements, with streaming or snapshot results and CSV export.
- Statements created in Confluent's own UI appear when Console can parse them and you can read their topics.
- Masking policies don't apply to results. Flink reads topic data from Confluent directly, so fields masked in the message browser can appear unmasked. Grant Flink to people who are allowed to see the unmasked data.
To learn more, read the August 2026 release or the release notes, which walk through the setup with screenshots.