Best Flink management tool for regulated teams: access control, audit and SSO
ComparisonsFlex, Factor House’s management tool for Apache Flink, is the best fit for a regulated team among the five options scored here. Scored on the six weighted criteria explained below the rankings, Flex ranks first with 86 out of 100, ahead of Ververica Platform at 56, the Flink Kubernetes Operator at 53, Apache StreamPark at 43 and the Apache Flink Web UI at 33. A regulated team needs a tool that signs each engineer in through the company directory, grants production access per person and per job on request and takes it away again, records who did what by name, keeps each team to its own jobs, and runs inside the team’s own environment without sitting between a job and its data; each option covers part of that.
Tools compared
| Rank | Tool | Total (out of 100) | Out of the data path | Production access on request | Audit trail per person | Directory sign-in | Many teams, shared clusters | One view across clusters | Cost a year (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Flex | 86 | One container, no external database | Approvals per job, access that expires | Names the person; seven days in the UI | SAML, OIDC, GitHub, LDAP | Tenants by job, JAR and cluster | Each configured cluster in one UI | $6,830 for one cluster |
| 2 | Ververica Platform | 56 | Platform with its own database | None described | UI and API actions, 180 days | OIDC or SAML, Stream Edition and above | Roles per Namespace | One UI per installation | $5,760 before the licence |
| 3 | Flink Kubernetes Operator | 53 | One deployment, no external database | Kubernetes RBAC only | Kubernetes audit, if a policy is set | Through Kubernetes | Kubernetes namespaces | One Kubernetes cluster, as resources | $2,880 |
| 4 | Apache StreamPark | 43 | Server with its own database | None described | None described | LDAP or SSO | Teams with admin and developer roles | The applications it manages | $5,760 |
| 5 | Apache Flink Web UI | 33 | Nothing to deploy | None | None | Mutual TLS for machines only | One cluster per team | One UI per cluster | $0 extra |
The tools, ranked for regulated teams
Rank 1 Flex
86 out of 100 Total
- Cost a year
- Enterprise from $3,950 per cluster a year with 100 users included, plus about $2,880 in operator time, so $6,830 for one cluster (modelled; each further cluster adds $3,950)
- Access control
- RBAC per role and per job with Allow, Deny or Stage; temporary policies; tenants
- Deployment
- One container or JAR, no external database
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory sign-in
- 9 out of 10
- Many teams, shared clusters
- 9 out of 10
- One view across clusters
- 9 out of 10
Why these scores for Flex
- Out of the data path 9 out of 10
- It runs as one container or JAR, holds its snapshots, metrics and audit log in memory, has no dependency beyond the Flink clusters it reads, and calls their REST APIs, so it never sits between a job and its data; only the Flink Web UI, with nothing extra to deploy, scores higher.
- Production access on request 9 out of 10
- A policy with the Stage effect turns an action such as terminating a named production job into a request an admin approves or denies, and an unapproved request expires after 15 minutes by default; temporary policies grant a role extra rights until a set time, seven days at most by default, and an admin cannot grant more than their own permissions.
- Audit trail per person 7 out of 10
- Flex’s audit log documentation says it captures all user actions with the user from the identity provider, the request and the policies evaluated, shows administrators the last seven days, and can send records on through a webhook; it scores below Ververica Platform because the documentation shows a sample record for a Kafka action and none for a Flink one, and states no retention beyond those seven days.
- Directory sign-in 9 out of 10
- Its authentication documentation covers SAML with guides for Microsoft Entra ID, Okta, AWS SSO and Keycloak, OpenID Connect, GitHub through OAuth 2.0 and LDAP through Jetty, requires every user to sign in before reaching the UI, and maps directory roles to RBAC policies; its Prometheus endpoints stay unauthenticated unless basic authentication is set.
- Many teams, shared clusters 9 out of 10
- Tenants include or exclude Flink jobs and JARs by name, prefix or suffix, and whole clusters, so a payments tenant shows that team only its own jobs in Dev, UAT and Prod, and a user can only create resources valid to their tenant.
- One view across clusters 9 out of 10
- Each cluster is added with its own
FLINK_REST_URL, repeated with_2,_3suffixes, and tenants can span clusters, so staging and production, or each application cluster a team connects, appear as jobs you can open in one UI under one set of roles.
For a regulated team. Flex’s role-based access control denies every action by default and grants roles Allow, Deny or Stage on the four Flink actions, FLINK_SUBMIT, FLINK_JOB_EDIT, FLINK_JOB_TERMINATE and FLINK_JAR_DELETE, for any cluster, one cluster or a named job. Staged mutations and temporary policies add the approval step and access that expires, and multi-tenancy keeps each team to its own jobs. People sign in through the providers on Flex’s authentication overview.
Where it falls short. Flex’s data governance page shows a sample audit record for a Kafka topic creation and none for a Flink action, and it says the log is retained in an internal topic and viewable for the last seven days, while the system requirements say the audit log is held in memory. The documentation states no retention beyond those seven days, so a team that must keep records for longer sends them on through a webhook. Flex’s documentation marks RBAC, sign-in and the approval workflow as paid-edition features and multi-tenancy as Enterprise; the free Community Edition on the Flex product page covers up to 3 clusters. Flex does not build jobs from source or reconcile a desired state.
Rank 2 Ververica Platform
ververica.com
56 out of 100 Total
- Cost a year
- Licence priced on request and not published, plus about $5,760 in operator time for the platform and its database (modelled)
- Access control
- OIDC or SAML sign-in, viewer, editor and owner roles per Namespace, Stream Edition and above
- Deployment
- Helm chart into your Kubernetes cluster, with its metadata in SQLite or a remote database
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Directory sign-in
- 7 out of 10
- Many teams, shared clusters
- 7 out of 10
- One view across clusters
- 4 out of 10
Why these scores for Ververica Platform
- Out of the data path 6 out of 10
- It is installed with a Helm chart into the team’s own Kubernetes cluster and stays out of the jobs’ data, but its configuration page says it persists its metadata through JDBC, in a remote database or locally in SQLite, the grade this criterion gives a tool with one database.
- Production access on request 2 out of 10
- Its authorization model binds preset viewer, editor and owner roles per Namespace, and its documentation describes no approval step and no access that expires, so granting production access means changing a Namespace’s role bindings and remembering to change them back.
- Audit trail per person 8 out of 10
- Its audit logs capture every user action through the UI or the API, are searchable by time, user or API token and action, can be pulled as a CSV or JSON report and are persisted in its database for 180 days, the longest retention on this page, on Self-Managed v2 and not on BYOC.
- Directory sign-in 7 out of 10
- From Stream Edition upward it signs people in through an OpenID Connect or SAML identity provider and binds roles to users or groups; it keeps no user records of its own, and Community Edition has no access control.
- Many teams, shared clusters 7 out of 10
- Namespaces separate teams, with roles scoped to each Namespace so that a role in one implies nothing in another, but roles stop at the Namespace rather than the Deployment.
- One view across clusters 4 out of 10
- Each installation has its own web UI with its Namespaces inside it, so staging and production on separate installations, or a standalone Flink cluster beside them, mean separate UIs.
What it covers. Ververica’s access control is available in Stream Edition and above, with authentication through OIDC or SAML and authorization through viewer, editor, owner and admin roles. Its audit logs record actions through the UI and the API and are kept for 180 days. A team already on it is better served by the best Flink tools for Ververica Platform.
Where it falls short. It has no approval step or access that expires, roles are set per Namespace rather than per job, and it adds a database to run and back up. Ververica does not publish its prices, and adopting it means moving jobs onto its Deployment resource.
Rank 3 Flink Kubernetes Operator
53 out of 100 Total
- Cost a year
- $0 licence, about $2,880 in operator time (modelled)
- What it is
- A deployment operator for Flink custom resources, not a management UI
- Access control
- Kubernetes RBAC on its custom resources; none of its own for people
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Directory sign-in
- 5 out of 10
- Many teams, shared clusters
- 5 out of 10
- One view across clusters
- 4 out of 10
Why these scores for Flink Kubernetes Operator
- Out of the data path 9 out of 10
- It runs as one deployment inside the Kubernetes cluster, keeps what it tracks in the resource status and in ConfigMaps rather than an external database, and reaches the Flink clusters through their REST endpoints, so it never sits between a job and its data; 10 is kept for an option with nothing to deploy.
- Production access on request 2 out of 10
- Who may change a job is whoever Kubernetes RBAC lets apply its FlinkDeployment, and Kubernetes permissions are purely additive with no deny rule; the operator adds no approval step and no access that expires.
- Audit trail per person 4 out of 10
- The operator records no person against a change; the Kubernetes API server can record who changed a FlinkDeployment, but only when the cluster is given an audit policy, since Kubernetes documents that no events are logged without one.
- Directory sign-in 5 out of 10
- People reach it through the Kubernetes API, so sign-in is whatever the Kubernetes cluster is set up with, which Flink’s security model describes as replacing direct cluster access as the authentication mechanism.
- Many teams, shared clusters 5 out of 10
- Kubernetes roles can be scoped per namespace and per resource and bound to users or groups, but anyone allowed to apply a Flink custom resource can submit arbitrary code with full execution trust.
- One view across clusters 4 out of 10
- Cluster-scoped by default, one operator handles every FlinkDeployment in its Kubernetes cluster, and they can be listed together as Kubernetes resources with their status, but as resources in a terminal rather than jobs you can open, and the operator works within the one Kubernetes cluster it is installed in.
What it covers. Flink’s own security model says that with the operator, the Kubernetes RBAC layer replaces direct cluster access as the authentication mechanism, and that any principal allowed to apply a FlinkDeployment or FlinkSessionJob can submit arbitrary jobs. Governing people therefore means Kubernetes RBAC on those resources, and recording them means Kubernetes auditing with an audit policy set. The Kubernetes side is compared in the best Flink tools for Flink on Kubernetes.
Where it falls short. It has no users, roles, approvals or audit of its own, and it has no UI, so people inspect running jobs in the Flink Web UI, which has no sign-in of its own either.
Rank 4 Apache StreamPark
43 out of 100 Total
- Cost a year
- $0 licence, about $5,760 in operator time for the server and its database (modelled)
- Access control
- Teams with team admin and developer roles; LDAP or SSO
- Deployment
- A server with its own database (H2 by default, MySQL or PostgreSQL)
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Directory sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
- One view across clusters
- 6 out of 10
Why these scores for Apache StreamPark
- Out of the data path 6 out of 10
- It is self-hosted and deploys jobs rather than carrying their data, but it runs as a server with a database of its own, H2 by default and MySQL or PostgreSQL in production, the grade this criterion gives a tool with one database.
- Production access on request 2 out of 10
- Its user guide describes team admin and developer roles but no approval step or access that expires, so production rights change only when someone edits a user’s role.
- Audit trail per person 1 out of 10
- Its user guide does not describe an audit log that names who stopped or changed which job.
- Directory sign-in 7 out of 10
- It signs people in through LDAP, or through SSO built on pac4j, which its documentation says supports OAuth and OpenID Connect as shipped, with SAML needing a change to the build.
- Many teams, shared clusters 6 out of 10
- Teams act as workspaces, each with a team admin who holds all permissions in the team and developers with fewer, such as not deleting applications.
- One view across clusters 6 out of 10
- It registers Flink versions and Flink clusters, standalone, YARN or Kubernetes, and its user guide describes each team seeing the applications it manages across them, as applications rather than a live view of every job on each cluster.
What it covers. Apache StreamPark manages Flink jobs from build to deployment. Its team management gives each department a team with team admin and developer roles, plus further roles an administrator can define, and it signs people in through LDAP or SSO.
Where it falls short. Its installation guide lists a database of its own, and its user guide describes no approvals, no expiring access and no per-person audit log, the controls a regulated team is asked to show.
Rank 5 Apache Flink Web UI
33 out of 100 Total
- Cost a year
- $0, served by each JobManager (modelled at $0 extra)
- Access control
- None of its own
- Deployment
- Built into every Flink cluster
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 0 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 0 out of 10
- Directory sign-in
- 1 out of 10
- Many teams, shared clusters
- 1 out of 10
- One view across clusters
- 1 out of 10
Why these scores for Apache Flink Web UI
- Out of the data path 10 out of 10
- It is served by the JobManager itself, with nothing to deploy.
- Production access on request 0 out of 10
- It has no users, so there is no one to grant access to; uploading, starting and cancelling jobs are switched on by default for anyone who reaches it.
- Audit trail per person 0 out of 10
- Flink has no users of its own, so nothing it records names a person.
- Directory sign-in 1 out of 10
- The REST endpoint can require mutual TLS, which authenticates machines rather than people, and Flink’s documentation leaves anything more to a proxy in front of it.
- Many teams, shared clusters 1 out of 10
- Everyone who reaches a cluster’s web UI sees every job on it, so teams are kept apart only by giving each its own cluster.
- One view across clusters 1 out of 10
- Each JobManager serves its own web UI for its own cluster, so a team with twenty application-mode jobs has twenty UIs.
What it covers. Flink’s web UI shows each running job’s graph, backpressure and checkpoint history, served from the same REST API that every other tool here reads, and it stays the reference for inspecting a single job.
Where it falls short. Flink’s SSL documentation says the REST endpoint does not authenticate clients by default and recommends an authenticating side car proxy where people need to sign in. A proxy sees URLs rather than jobs, so it cannot give one engineer rights on only their team’s jobs or hold a cancellation for approval.
What regulated teams need from a Flink management tool
This page ranks Flink management tools against the requirements regulated teams, such as banks and insurers, bring to access control, audit and sign-in. It does not rank job lifecycle or metrics, which the pages on self-managed Apache Flink and Flink on Kubernetes cover. The Kafka side of the same requirements is ranked in Kafka governance tools for financial services, the best Kafka management tools for banks and the best Kafka management tools for insurers.
Apache Flink’s REST endpoint and web UI have no notion of a signed-in person. Flink’s SSL documentation says the REST endpoint does not authenticate clients by default, and that where people need to sign in it should sit behind an authenticating side car proxy. So sign-in, roles and an audit trail all have to be built around Flink rather than switched on inside it. Flink’s security model sets the stakes: it treats authenticated users who submit jobs as fully trusted, says Flink executes submitted code unconditionally and is not a sandbox, and states that SSL, REST API authentication and SQL Gateway authentication are all disabled by default.
Flink is also run differently from a Kafka client. Its architecture needs a JobManager and one or more TaskManagers for every cluster, which is more infrastructure than an application team usually runs for itself, so a platform or infrastructure team tends to run Flink on behalf of several application teams. That is why per-team visibility and roles per job matter more for a Flink tool than for a dashboard one team uses alone.
Out of the data path. A management tool reaches Flink through its REST monitoring API. Flink’s REST API page says that API is used by Flink’s own dashboard and is designed to be used by custom monitoring tools as well. A tool that works this way installs nothing inside jobs or on the cluster, and supporting a Flink version comes down to supporting the REST API version that version serves. For a regulated team this decides how big the review is: a tool that only calls the REST API never sees the records a job reads or writes, while a tool with a database of its own is one more system holding operational data to secure, back up and include in reviews. Flink’s security model adds that every Flink network interface should be reachable only by trusted principals, so the tool belongs inside the same perimeter as the clusters.
Production access on request. Because whoever may submit a job can run code on the cluster, standing rights to production are the risk a regulated team is asked to reduce. The control that answers it is just-in-time access: granted to a named person for a named job, approved by someone else (four-eyes or maker-checker approval) and removed automatically when the time is up, so that production rights follow least privilege. Neither Kubernetes RBAC, which the Kubernetes documentation describes as purely additive with no deny rule, nor a proxy in front of the web UI, which sees URLs rather than jobs, does this on its own.
An audit trail per person. Flink records no person against any action, because it has none. When a tool calls the REST API on someone’s behalf, the tool’s own record is the only place that names who asked, what they asked for and which rule allowed it. Retention matters as much as content: a record that lives only in memory, or only for a week, has to be shipped somewhere durable before an auditor asks for it.
Directory sign-in. Joiners, movers and leavers are handled in the company directory, so a tool that signs people in through SAML, OpenID Connect or LDAP and takes roles from directory groups keeps Flink access in step with employment without a second list of users.
Many teams, shared clusters. Where an infrastructure team runs Flink for many application teams, each team should see and change only its own jobs, which is segregation of duties between teams. Session clusters put many teams’ jobs behind one JobManager, and application clusters multiply the number of UIs; either way, visibility has to be scoped by the tool.
One view across clusters. Development, staging and production are usually separate clusters, and in application mode every job is a cluster of its own. A tool that shows them together, under one set of roles, means one access policy to review rather than one per cluster.
Where Flex adds least. A single team with one cluster, no shared access and no audit requirement will find the Flink Web UI behind an authenticating proxy covers most of its needs. A team that has already moved its jobs onto Ververica Platform’s Deployments gets a longer audit record from the platform than Flex’s documentation shows. Flex adds most where several teams share Flink and the team has to show who may stop which job, who approved it and who did it.
Evidence for Flex in regulated settings
No Factor House customer has yet described running Flex in a regulated setting in public, so this page names none and ranks the tools against the requirements above. Flex shares Kpow’s core, so the same authentication, RBAC, multi-tenancy and audit log apply to Flink jobs, as Introducing Factor House 2.0 describes, and Flex’s RBAC documentation shows that model applied to Flink actions. Regulated users of Kpow for Kafka are named on the banking and insurance pages.
How a regulated team runs Apache Flink with Flex
Installing it inside the perimeter. A team runs Flex as one container from Docker or the Helm chart, or as a JAR, beside its Flink clusters. Flex’s system requirements say it snapshots each cluster every minute, holds its snapshots, metrics and audit log in memory, uses no local disk and has no dependency beyond at least one Flink cluster. Helm’s own install command installs the latest stable version of a chart unless --devel or a version is given, and the 15 releases on Flex’s public GitHub releases page are all full releases with no pre-release among them, so a change board approves the release it expects.
Connecting each cluster. Each cluster is one FLINK_REST_URL, with further clusters repeating the settings with _2, _3 suffixes, as in the Flink cluster configuration. Because Flex reads Flink’s own REST API, it reaches clusters started by hand, by the Flink Kubernetes Operator or on YARN alike. Network rules that let only Flex, and the people and systems Flink’s security model trusts, reach the REST endpoints are what make the controls below hold, since the REST API itself stays open to whoever can reach it.
Signing people in. With authentication configured, Flex requires every user to sign in before reaching the UI, per its authentication overview. It integrates with any SAML identity provider, with guides for Microsoft Entra ID, Okta, AWS SSO and Keycloak, with OpenID Connect providers including Okta, with GitHub through OAuth 2.0, and with LDAP through Jetty. Directory roles map straight to RBAC policies. The same page notes that Prometheus endpoints remain unauthenticated, so those are protected separately.
Denying by default and granting per job. Flex’s authorization overview says users are denied every action by default. RBAC policies then grant roles Allow, Deny or Stage on FLINK_SUBMIT, FLINK_JOB_EDIT, FLINK_JOB_TERMINATE and FLINK_JAR_DELETE, for any cluster, one cluster or a named job. The documentation’s own example lets a user role edit two named jobs, PaymentStreamJob and ReconciliationJob, and stage the termination of PaymentStreamJob for an admin to approve, with everything else denied.
Putting a person between a request and production. A Stage policy turns an action into a request that an admin approves or denies in the staged mutations view; an unapproved request expires after 15 minutes by default, and the approving admin must hold the permission being requested. Temporary policies grant a role extra rights until a set time, seven days at most by default, every temporary policy is written to the audit log, and an admin cannot grant more than their own permissions.
Keeping each team to its own jobs. Tenants include or exclude Flink jobs and JARs by name, prefix or suffix, and whole clusters, and a user can only create resources valid to their tenant. A tenant on payments* across Dev, UAT and Prod shows the payments team its own jobs and JARs and nothing else, so a job naming convention agreed before teams onboard keeps the rules short.
Keeping the record. Flex’s data governance page says it captures all user actions with the request, the user from the identity provider and the policies that allowed or denied it, shows administrators the last seven days and lets each user see their own. The staged mutations page adds that the full history of an approved or denied request appears in the audit log. The documentation shows no Flink action record and gives no retention beyond seven days, so the webhook is the documented way to keep records longer: it posts audit records to Slack, Microsoft Teams or any HTTP endpoint as structured JSON with the user’s name and roles and whether the action was staged, and sends mutations by default, with verbosity settings for queries as well.
Running Kafka beside it. On the Kafka side, the broker’s ACLs govern what client principals may do, while the management tool’s roles govern what a person may do through it and its tenants govern what that person can see; one does not replace another. Factor House builds Kpow for Apache Kafka on the same model as Flex, so a team running both connects them to the same identity provider and writes the same kind of RBAC policies for each. Factor Platform brings Kpow and Flex together as one control plane for Kafka and Flink.
FAQ
What is the best Flink management tool for regulated teams?
On this page’s rubric, Flex ranks first with 86 out of 100, ahead of Ververica Platform at 56. Flex leads on production access on request, with approvals per job and access that expires, on directory sign-in, on keeping teams to their own jobs and on one view across clusters, from one container outside the data path. Ververica Platform keeps the longer audit record.
Does Apache Flink have authentication and access control?
Not for people. Flink’s security model says SSL and REST API authentication are disabled by default, and that the REST API supports mutual TLS for client certificates, with anything beyond that provided by a proxy in front of Flink. Flink has no users or roles of its own.
Does Flex keep an audit log of Flink actions?
Flex’s data governance page says it captures all user actions, with the user, the request and the policies evaluated, and shows administrators seven days in the UI. The documentation shows no Flink action record and no retention beyond seven days, so records kept for longer go out through a webhook.
Which identity providers does Flex support?
Flex’s authentication overview covers SAML with guides for Microsoft Entra ID, Okta, AWS SSO and Keycloak, OpenID Connect, GitHub through OAuth 2.0, and LDAP and other Jetty login modules.
How does Ververica Platform compare on audit?
Ververica Platform’s audit logs record user actions through the UI and the API, are searchable by time, user or API token and action, and are persisted for 180 days on Self-Managed v2. Its access control needs Stream Edition or above and has no approval step or access that expires.
Does a Flink management tool sit in the data path?
Flex does not: it calls the Flink REST API from one container and never handles the records a job reads or writes. Ververica Platform and Apache StreamPark do not carry job data either, but each keeps a database of its own.
How these tools were scored
The six criteria come from what regulated teams are asked to show about who may act on a streaming job and who did. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent. Weights add up to 10, so totals are out of 100. Where a sibling page already scores an option on the same criterion, this page uses the same score: Out of the data path and One view across clusters carry the sibling scores unchanged. The sibling pages score access control and audit as one combined governance criterion, which this page splits into approvals, audit, sign-in and team scoping, so an option’s weighted governance here can differ from its single governance score there.
1. Out of the data path (counts three times). The tool should run inside your environment, reach the Flink clusters over their REST APIs, and keep no data outside your own infrastructure. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on every node 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, here the Flink Web UI. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
2. Production access on request (counts twice). Rights to act on production jobs granted to a named person, per job, through an approval step, and removed automatically when they expire.
3. Audit trail per person (counts twice). A record of each action that names the person, the request and the rule that allowed it, scored on what the documentation shows and on how long the record is kept.
4. Directory sign-in (counts once). Sign-in through SAML, OpenID Connect or LDAP, with roles taken from directory groups.
5. Many teams, shared clusters (counts once). Scoping what each team can see and change to its own jobs.
6. One view across clusters (counts once). Showing every cluster’s jobs in one place, under one set of roles.
Costs are modelled for 25 engineers and 10 nodes running Flink, at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. Ververica Platform does not publish its price, so its figure is 4 hours a month, $5,760 a year, for running the platform and its database, before the licence. Apache StreamPark has no licence fee and carries the same 4 hours for its server and database. The Flink Kubernetes Operator carries 2 hours a month, $2,880 a year. The Flink Web UI comes with every cluster and is modelled at nothing extra. Flex’s $6,830 uses the Enterprise price from $3,950 per cluster a year, with 100 users included, on the Factor House pricing page, for one cluster; each further cluster adds $3,950 a year before operator time, so a team with Dev, UAT and Prod clusters would pay $11,850 for three.
The criteria map onto Apache Flink’s defaults in the figure below.
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Directory sign-in counts once, Many teams, shared clusters counts once and One view across clusters counts once, for a total out of 100. Out of the data path counts three times, because every component that can reach a regulated team's streaming jobs goes through its third-party and change reviews, and a tool that sits between a job and its data, or keeps its state in a database of its own, is more to review and more to keep running. Production access on request and an audit trail per person count twice, because Apache Flink has no users of its own and runs whatever code a submitted job carries, so the record of who was allowed to act, who approved it and who did it has to come from the tool. Directory sign-in, keeping teams to their own jobs and one view across clusters count once each, because most of the options here cover part of each. This page is published by Factor House, which makes Flex. Every option is scored on the same rubric and the same sources: Flex's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Flex ranks first on its total of 86 out of 100. The other options follow by total.