Open-source web UIs for Kafka administration: when a UI helps and when it should not be the tool
A platform team supporting many developers often needs one answer: how do people see topics, consumer groups and messages without a commercial console? An open-source web UI such as kafbat UI can cover browsing and day-to-day inspection: listing topics, reading partition and consumer group state, and checking recent messages. Privileged changes, such as altering topic configuration, resetting offsets or managing ACLs, should stay in controlled tooling where each action is reviewed, scripted and logged. Apache Kafka itself is licensed under Apache-2.0 and has no paid edition from the project, so a web UI is a separate component you choose, deploy and secure yourself.
Because the UI is a separate application, it adds its own attack surface and its own upgrade cycle. It connects to brokers with credentials, so it must be treated as a privileged client. Confirm which authentication options the version you select supports, how it maps users to roles, and whether it can be made read-only at the configuration level rather than relying on users to behave. Check where it stores any local state, which logs it writes and whether message viewing can expose sensitive payloads to people who should only see metadata. Its authorization model should be compared against the ACLs your brokers already enforce, not treated as a replacement for them.
Use the UI for visibility and keep write paths in the CLI and automation that your change process already governs. The Kafka security overview describes the SASL and TLS controls the UI must also satisfy, and the authorization documentation explains how broker-side ACLs remain the final gate. A UI that cannot be audited, or that holds broker credentials with broad rights, is a reason to stop and choose a narrower tool or none at all.
Which UI options fit which team
This table compares the main configuration choices for a self-hosted Kafka web UI: access mode, cluster scope, login method and network exposure. Read each row as a decision, then check the trade-off column before choosing a default for production. The main takeaway is that most teams should start read-only, internal and single sign-on backed, and widen access only with a named need.
| Configuration choice | When it fits | Trade-off |
|---|---|---|
| Read-only deployment | Platform, support and most application teams who need to browse topics, consumer groups and lag | Cannot create topics, change configs or reset offsets, so those changes stay in the CLI or pipelines |
| Write-enabled deployment | Small non-production environments or a platform team that performs routine changes through the UI | Any user with write rights can alter production state, so role separation and audit trails must be confirmed first |
| Single-cluster configuration | One production cluster or a team that owns one environment | Operators switching between environments must manage several instances or context changes |
| Multi-cluster configuration | Platform teams that run development, test and production clusters and want one console | One misconfigured connection or shared login can expose more clusters, so per-cluster permissions need confirming |
| Local accounts | Small pilots or labs with a handful of administrators | Passwords, offboarding and MFA become manual work that the team must maintain |
| OAuth or LDAP login | Organizations that already run an identity provider and want group-based access | Requires identity configuration, group mapping and testing of role assignments before rollout |
| Internal-only endpoint | Production clusters and any UI that can reach broker admin APIs | Engineers working remotely need VPN or bastion access, which adds operational steps |
| Exposed endpoint behind a gateway | Rare cases where a gateway enforces TLS, MFA and access logs in front of the UI | Larger attack surface; confirm TLS termination, session handling and rate limits with your security team |
How to deploy a Kafka UI against a secured cluster
This sequence connects a Kafka web UI to a secured cluster through a read-only identity, encrypted connections and controlled user access, so the UI can inspect topics and consumer groups without being able to change them.
Create a dedicated read-only principal
The cluster administrator creates a separate Kafka principal for the UI, using SCRAM-SHA-256 or SCRAM-SHA-512 credentials or an OAUTHBEARER identity from your provider. Grant it only describe and read-style access to the topics and consumer groups the UI should display, and do not give it cluster-level admin rights. Check the result with the ACL listing command for that principal and confirm it holds no create, alter or delete entries. Done when the principal can list metadata but a test create or alter request from it is refused.
Enable TLS on the UI connection
Configure a dedicated listener on the brokers that accepts TLS connections and point the UI at the cluster's CA bundle, so the UI-to-broker traffic is encrypted and the broker certificate is verified. Use a SASL mechanism over that listener so the principal authenticates on every connection. Confirm the handshake by connecting with the same client settings from a host in the UI network and checking that the broker certificate chain validates. Done when the connection succeeds with verification enabled and fails when the wrong CA is supplied.
Configure authentication for UI users
Decide how people sign in to the UI itself, using the identity provider your organization already runs where the UI supports it, or a local account store if it does not. Confirm the exact login options for your chosen UI version in its documentation before relying on them. Map users to the authentication method and keep the cluster principal separate from individual user identities, so that the audit trail shows who viewed what. Done when a test user can sign in and an unauthenticated request to the UI is redirected or refused.
Define UI roles and limits
Set up roles inside the UI so that viewing topics, messages and consumer groups is separate from any action that would alter state. Where the UI offers role-based access control, assign view-only roles to most users and restrict any elevated role to a small named group. Confirm the role definitions in the UI's own configuration, and record them in your change system. Done when a user with a view-only role sees no create, edit or delete controls, and a user outside every role sees no clusters at all.
Deploy behind an internal reverse proxy
Publish the UI only on an internal address behind a reverse proxy that terminates TLS for browser traffic and forwards requests to the UI process. Restrict network access to the corporate network or your VPN, and disable direct access to the UI's port. Set the proxy to pass the authenticated user identity only where the UI is configured to trust it. Done when the UI is reachable through the proxy from an approved network, unreachable from outside it, and its direct port does not respond from a client host.
Verify that write actions are blocked
Test each write path from the UI with the read-only principal, including creating a topic, altering a configuration, deleting a topic, resetting offsets and producing a message. Repeat the same attempts through the cluster CLI using the same principal to confirm the broker enforces the restriction, not only the UI. Record each refused request and the authorization error returned. Done when every write attempt fails at the broker, because the UI check is a convenience and the ACLs are the control.
Record the configuration and review access
Store the principal's ACL definitions, the TLS settings, the UI role mapping and the proxy configuration in version control, and note who approved each. Schedule a periodic review of the principal's ACLs and the UI user list against the current team roster. Confirm the stored definitions match the running configuration by comparing them with the live ACL listing and the UI settings. Done when a second administrator can rebuild the same read-only setup from the stored files.
Read-only production versus write-enabled staging
Production should be the environment where a UI can look but not change anything by default. Operators use the UI to inspect topics, consumer groups, partition placement and broker health, while topic creation, configuration changes, offset resets and deletions go through reviewed change records and automation. The UI role that grants this view should map to a narrow set of read permissions, and the team should confirm that the tool does not expose write actions to that role, even when a button is hidden.
- Restricted read roles: Create a UI role limited to describe and read operations, and confirm which Kafka principal the UI uses for each role in your deployment.
- Hidden write paths: Disable topic, ACL and offset actions in the UI configuration where the tool supports it, and test that they fail even when called directly.
- Audit of every session: Record who logged in, which view they used and any action attempted, and forward those logs to your central log store.
- Named accounts only: Avoid shared operator logins so that every read and change can be traced to a person.
- Network placement: Reach the UI only through your internal access path, not from the public internet.
Before go-live, confirm with your security team which UI actions the audit log captures and whether they match your change management evidence.
Non-production environments are where developers need to create topics, adjust configurations and experiment with consumer offsets. Write access here should still be bounded by Kafka ACLs, scoped to the team's topic prefixes or resource patterns, so a developer's changes cannot reach another team's data. The UI can make these tasks faster, but the access boundary is set in the cluster, not in the interface.
- Prefix-scoped grants: Grant create, alter and read operations on topics and consumer groups that match each team's naming prefix, as defined in your authorization design.
- Separate staging identities: Give developers their own principals in staging instead of sharing the service accounts used by applications.
- Change visibility: Keep write-enabled tools logged so that a staging change that later moves to production can be reproduced in code.
- Promotion path: Require that topic definitions used in production come from version-controlled manifests, not from edits made in the UI.
- Data limits: Mask or avoid production records when developers browse messages in staging, since UI message viewers can expose payloads.
Confirm with your platform team how staging ACLs are created and reviewed, and whether the UI can read the same ACL metadata that enforces these rules.
An incident may require a change in production, such as an emergency offset reset or a configuration change that the normal review process cannot wait for. A break-glass path gives a small set of trained people a documented way to act, with stronger logging and after-the-fact review. It should not be a shared admin login kept in a password manager. Kafka's default behavior helps here: with the StandardAuthorizer in KRaft mode, a resource without an ACL is restricted to super users unless allow.everyone.if.no.acl.found is set to true, so emergency rights must be granted deliberately and are easy to withdraw.
- Pre-approved roles: Define the incident roles and the named people who may hold them, and confirm how they are activated and revoked.
- Time-limited access: Issue elevated credentials for the incident window only, with a documented revocation step.
- Recorded actions: Capture the command or UI action, the reason and the outcome, and link it to the incident ticket.
- Post-incident review: Compare the changes made during the break-glass window with the expected state and revert anything that should not persist.
- Tested drill: Run the path in a non-production environment so that the steps and access are known before an incident.
Confirm your organization's rules for emergency privileged access with your security and compliance leads before writing the procedure.
The UI role model is an application-level control. Kafka's authorizer decides what each principal can actually do on the cluster. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log, so the same rules apply whether a request comes from the UI, a client application or the command line. If a UI role says read-only but the principal the UI uses has broad cluster rights, the cluster will still allow the change. For this reason, the UI should be treated as one client among many, with its own principal and minimal grants.
- Principal per tool: Give the UI its own Kafka identity, authenticated with SSL or a supported SASL mechanism, so its rights can be set separately from applications.
- Explicit default posture: Leave allow.everyone.if.no.acl.found at its default unless you have a documented reason to change it, and verify this setting in your deployment.
- Least-privilege grants: Give the UI principal only the describe and read operations its views require in production.
- Direct testing: Attempt a write through the UI's principal with a Kafka command-line tool to confirm the cluster denies it.
- Review cadence: Re-check the UI principal's ACLs whenever the UI or cluster version changes.
Before relying on any UI role model, confirm with your Kafka administrator which principal the tool uses and which ACLs apply to it.
Security risks in a Kafka UI deployment
A Kafka web UI sits between people and the cluster, so it inherits every privilege the cluster grants it and exposes the data that flows through topics. The cards below cover the places where a UI deployment most often weakens a Kafka environment that was otherwise secured, and the control to apply at each one.
Service account privilege
Most UIs connect to brokers with one shared service identity. If that identity can read every topic, alter configurations and manage ACLs, then every user of the UI inherits those rights, whatever the UI shows them. Map each UI role to a narrower broker identity, and confirm which operations the UI actually calls before granting access. Check that the UI cannot do more than its most restricted user needs.
Unauthenticated message access
A topic browser shows message keys and values to anyone who can reach the page. Those payloads often contain personal data, account identifiers or health and payment details, so an open UI turns a network path into a data disclosure. Require sign-in on every route, including health and API endpoints, and confirm that the UI does not serve a default login bypass. Treat the message viewer as a data access tool with its own approval.
TLS gaps to brokers
The UI usually holds broker credentials and sends them with every request. If the connection from the UI to the brokers runs in plaintext, or the UI accepts any certificate, a network attacker can capture credentials or message content. Kafka supports SSL/TLS for clients and tools, and mixed listeners are possible, so the UI may quietly use an unsecured one. Point the UI only at secured listeners and verify the certificate chain it trusts.
Payload logging
Application logs, debug output and error traces from the UI can copy message bodies or search queries into a central log store. That store is often more widely readable than the cluster, and retention there is rarely planned. Set the UI log level to avoid payloads, redact fields in exported logs, and confirm which log sinks receive them. Test with a sample message that contains a marker value and search the log store for it.
Plugin and image supply chain
UI features often arrive as plugins, extensions or container images pulled from public registries. A tampered or abandoned component runs with the UI's broker credentials and sees every message it displays. Pin image versions by digest, build from a copy you mirror into your registry, scan the image before deployment, and review each plugin's source and maintenance status. Keep a record of which build is running in production.
Read-only and change controls
A UI that can publish, delete topics or alter configurations makes a browser session a production change path with no review. Turn off write operations in production, or restrict them to a named group that uses the same change process as the CLI. Log every administrative action with the user who performed it, and check that those audit records are kept outside the UI itself.
Limits to confirm before you commit to a UI
A Kafka web UI sits between your operators and your brokers, so its limits become your limits. Confirm each item below in your own environment before you grant write access, because the UI's version support, authentication, permissions and maintenance decide how much you can trust it in production.
Kafka version compatibility
Check that the UI supports the Kafka release you run or plan to run. The supported Kafka releases on the downloads page are 4.1.2, 4.2.2 and 4.3.1, and older lines are archived. Confirm the UI's admin client version against your brokers, especially if you run a release that is not the latest. Also confirm that the UI can reach KRaft controllers if it displays quorum or metadata information.
SASL mechanism support
Kafka supports SSL and several SASL mechanisms, including GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. A UI can only connect to a listener using a mechanism its client library implements. Confirm which mechanisms the UI supports, whether it can present a client certificate for mutual TLS, and whether it stores those credentials in a way your secrets policy allows.
RBAC granularity per cluster and topic
Many UIs offer roles that apply to the whole application, not to individual clusters or topics. Test whether you can give one team read access to a single topic on one cluster, and whether write actions such as deleting topics, altering configurations or resetting offsets can be disabled separately. Kafka's own ACLs still apply underneath, so the UI's permissions should map to them rather than replace them.
Message size and rendering limits
Browsing a topic in a UI usually means deserializing and rendering records in a browser or server process. Confirm the largest message the UI will display, how it handles Avro, Protobuf or JSON Schema payloads, and whether it can fetch a message from a given offset without loading the whole partition. Large or binary records may be truncated or fail to decode, so test with your real payload shapes.
Read-only mode for production
Confirm that the UI can be switched into a read-only mode per cluster, and that the setting is enforced on the server rather than only hidden in the interface. A read-only mode that the backend ignores does not protect production. Test it with an account that holds write permissions in your identity provider, and record the result as evidence for your change process.
Maintenance activity of the project
A UI that falls behind Kafka releases can break on new admin APIs, and an unmaintained project may leave security issues unpatched. Review the project's release history, open security advisories, issue response times and the number of active maintainers in its public repository. Record the date of your review, because the project's status can change after you adopt it.
Questions buyers ask before adding a Kafka UI
What does it cost to run an open-source Kafka UI if the license is free?
The license is zero, but the running cost is staff time and infrastructure. Someone hosts the UI, reviews its container image and dependencies, applies upgrades, configures authentication and roles, and keeps audit logs of who changed what. Hosting is usually small compared with that effort. Ask any partner to split a quote into one-time work (design, integration with your identity provider, hardening, initial rollout) and recurring work (patching, upgrades, access reviews, on-call for the tool itself). The main cost drivers are how many clusters the UI must reach, how many identity groups map to roles, and how strict your change control is. The Apache Kafka project itself is licensed under the Apache License 2.0, so the UI decision does not add a broker license.
How long does a Kafka UI deployment take?
The duration depends mostly on authentication integration. A UI running with a local account store and no SSO can be placed in a test environment quickly, but that setup is not suitable for production administration. Connecting to an existing OIDC or LDAP provider, mapping groups to read, write and admin roles, and testing failure cases such as expired sessions and removed users takes more work. Cluster connectivity matters too: TLS certificates, SASL credentials and network paths to every broker must be checked, and each cluster adds verification. A fixed-scope engagement lets you agree timelines in writing before work starts, so ask for the duration of each phase tied to the specific identity provider and cluster count you have.
Can our team deploy a Kafka UI alone using the documentation?
Yes, a capable platform team can deploy a Kafka UI using the project documentation and the vendor documentation for the UI, provided it has someone who understands Kafka security settings and your identity provider. The harder parts are rarely the install command. They are choosing which roles may see credentials or change topic configuration, keeping the UI off the public internet, handling secrets for broker connections, and proving that production clusters are read-only for most users. If those decisions are already owned by your security team, a self-run deployment is realistic. If not, a short design review with a partner can settle them before you build. Confirm the UI's current release and support status yourself before you pin a version.
Does a Kafka UI replace the command line and automation?
No. A web UI is useful for browsing topics, inspecting consumer group lag, reading recent messages and making small, supervised changes. It does not replace the Kafka command-line tools or automation for repeatable work. Partition reassignment, offset resets, broker removal and ACL changes should be scripted, reviewed, and recorded in version control so they can be repeated and audited. Infrastructure definitions for topics, quotas and ACLs belong in code. Many teams keep the CLI for incident response and use the UI for day-to-day visibility. Decide up front which operations are allowed through each path, because a UI that can change everything becomes the unofficial change process.
How is read-only mode enforced at the Kafka layer?
Read-only mode should be enforced by Kafka authorization, not only by hiding buttons in the interface. The UI connects to each cluster with its own principal, and Kafka's authorizer decides what that principal can do. In KRaft clusters the StandardAuthorizer stores ACLs in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. A read-only principal should therefore hold only describe and read permissions on the topics and groups it needs, with no write, alter or delete rights. Users then authenticate to the UI, and the UI maps them to the right principal, so a user cannot escalate by using a different path. Test this by attempting a write from the UI and from a client using the same credentials. Confirm the exact operation names with the Kafka authorization documentation for your release.
Should a Kafka UI be exposed to every engineer on the network?
No. A Kafka UI is an administrative surface that can reach every broker, and it may display message contents that contain personal or regulated data. Restrict it to a named group of users, place it behind your identity provider with multi-factor authentication where your policy requires it, and keep it off public networks. Enable TLS between the UI and brokers, and store broker credentials in a secrets system rather than in plain configuration files. Write down who may reach production clusters from it, and review that list on a schedule. These controls are ordinary platform hardening, but they are easy to skip when a tool is installed for a quick look at a topic.
What should we check before upgrading a Kafka UI?
Check the UI's release notes for changes to authentication, configuration keys and supported Kafka client versions, then test the upgrade against a non-production cluster that matches your security settings. Kafka itself has its own compatibility rules: rolling upgrades are supported from each release in the past year to the latest version, and the Kafka downloads page lists the currently supported releases. A UI built against an older client library may not show newer broker features correctly, so confirm compatibility with the brokers you run. Keep a rollback plan, and record the UI version, its configuration and role mappings in version control so the upgrade can be reproduced.
What the work needs from your team
A UI for Kafka is only as safe as the identity and access model behind it, so the first inputs to gather are the ones that decide who can log in and what they can do. Your team needs to provide the details of the identity provider that will sign users in (protocol, issuer, client registration and the group or claim names that carry role membership), plus a named owner who approves how those groups map to UI roles. Without that owner, role mapping tends to drift into shared accounts or broad admin groups. Ask the identity team to confirm which claims they can release to the tool and how group membership changes are propagated.
Next, the cluster security configuration determines what the UI can connect to. Share the listeners the UI must reach, the TLS trust chain for broker and controller endpoints, and the SASL mechanism each account will use. The Kafka security overview covers SSL and the documented SASL mechanisms, and the UI's own connection credentials should be a dedicated principal with only the rights it needs. Map the network zones too: which subnets the UI sits in, whether it can reach the brokers directly or only through a proxy, and whether administrators reach it through a bastion or VPN. Ask your network team to confirm these paths before scoping, since a UI placed in the wrong zone is often the cause of an outage.
Finally, decide which environments accept write actions. Most teams allow read-only browsing everywhere and restrict topic creation, deletion, offset changes and ACL edits to non-production or to a short list of approved operators in production. Record that decision per environment, because it sets the RBAC roles, the audit requirements and the change process. DeployOpen scopes these inputs in writing before work starts, and the quote follows from that written scope, so the more precisely your team answers these questions, the more precisely the scope and quote can reflect your environments.
How the rollout is phased
The sequence moves the UI from agreed roles and environments through a lab build, a small pilot and a read-only production launch, ending with handover that the operations team can run without the implementer. Each phase closes with a written acceptance check so governance decisions are made before users get access.
Scope roles, environments and access rules
Platform owners, Kafka administrators and the security lead agree which teams need the UI, which clusters it will reach and which actions each role may take, such as viewing topics, browsing messages or changing consumer group offsets. DeployOpen documents this as a role matrix tied to your identity provider groups and lists which clusters are production. The step closes when the matrix is signed off by the people who own the clusters and the access policy, and no role grants write access that was not explicitly approved.
Build and harden the UI in a lab
The team deploys the chosen web UI against a non-production Kafka cluster inside your infrastructure, connects it to your identity provider or the approved authentication method, and applies the agreed role mapping. Engineers test each permission against the matrix, confirm TLS and credentials are configured for the UI's connections to brokers and any Schema Registry or Connect clusters, and disable features that the matrix does not allow. The step closes when every role has been tested with an account that should be allowed and one that should be denied, and the results are recorded.
Confirm read-only behavior before any pilot
Before users touch the system, the team checks that the production profile blocks topic creation, deletion, configuration changes, offset resets and message production, and that the setting holds after restarts and upgrades of the UI. Because feature names and read-only options differ between UI releases, the exact settings should be confirmed against the release you deploy, not assumed from older guides. The step closes with a test record showing each blocked action returning a denial in the audit trail.
Pilot with a small named user group
A handful of named engineers from one or two teams use the UI on the non-production cluster for their normal investigation tasks, such as checking consumer lag, inspecting a dead-letter topic or confirming partition layout. The platform owner collects a log of questions, permission gaps and features people wanted to use but should not have. The step closes when the pilot group confirms the views they need work, the denied actions were the ones expected, and each finding has a decision: fix, accept or remove.
Launch to production in read-only mode
The read-only production profile is enabled for the approved roles on production clusters, with login, authorization decisions and access to message contents logged. Changes still go through the CLI, infrastructure code or the existing change process, which keeps the UI from becoming a second control plane. The step closes when the first access review confirms that only approved users reached production and that the logs show each session, with a named owner receiving the reports.
Hand over runbooks and ownership
DeployOpen delivers runbooks for deploying and upgrading the UI, rotating its credentials, adding a cluster, changing a role mapping, and responding to a reported exposure of message data. The document also lists which tasks stay in the CLI and automation, such as partition moves and offset resets, and who approves them. The step closes when your operations team performs one supervised role change and one UI upgrade in the lab with the runbooks, and the handover is accepted in writing.
How DeployOpen scopes a Kafka UI engagement
A Kafka UI engagement is scoped in writing before any work starts. The written scope names the platform, the UI component to be deployed (kafbat UI or another open-source option selected during discovery), the clusters it will connect to, the identity provider and role mapping, the read-only policy for each environment, and the list of deliverables. Timelines are agreed in the same document so that both sides know what is handed over, in what order, and what the client must provide, such as a test cluster, an OIDC client registration, TLS certificates and named reviewers. Ask for the scope in writing before comparing quotes, because the cost of a UI project follows from how many clusters, identity sources and roles are in it.
Scope questions specific to this topic are the ones that change effort most. Confirm how many Kafka clusters the UI must reach, whether each cluster already uses SSL or SASL with a known mechanism such as SCRAM-SHA-512 or OAUTHBEARER, and whether the UI service account needs the same authorization rights as human users. Confirm also whether the team wants the UI to change topic configuration, consumer group offsets or ACLs, or whether those actions stay in the CLI and automation. Each answer adds or removes test cases, so the written scope should list them explicitly. Ask the vendor or project documentation to confirm any feature the UI must provide before it is written into a deliverable.
Retainers are a separate, optional agreement. They cover recurring work after go-live, such as upgrading the UI image, re-testing role mappings after identity changes, reviewing audit logs, and handling Kafka client or broker upgrades that affect the UI. Because Apache Kafka 4.x releases are supported on a time-based plan, the UI and the cluster will need periodic changes, so ask whether the retainer includes testing against each supported Kafka release. Whether a retainer is worth buying depends on how often your team expects change, so ask for the recurring scope, response expectations and what is excluded, and keep it separate from the one-time build in your procurement records.
How DeployOpen delivers Kafka administration tooling
DeployOpen plans, installs and hardens self-hosted open-source platforms inside your own infrastructure, including the admin UI around a Kafka cluster. We scope the UI's access model, read-only rules and CLI boundaries in writing before work starts, then hand over a tested, documented setup your team can run.
How we scope
- Engagements are fixed-scope, with the UI features, users and clusters agreed in writing first
- We list which Kafka clusters the UI connects to and which environments stay read-only
- The written scope names the authentication source, role mapping and actions that stay in the CLI
- Ongoing support and upgrades are available as a retainer after handover
How we build
- We deploy the UI inside your network, accounts or data centers, not as a hosted console
- Authentication and role-based access are configured against your identity provider and tested per role
- Read-only mode is verified on production clusters before any write-enabled access is granted
- Cluster connections use the TLS and SASL settings your Kafka security model already requires
How we hand over
- You receive the deployment configuration, role matrix and access runbook as version-controlled files
- We document which operations are performed in the UI, the CLI or automation, and why
- Your team runs a walkthrough of login, role checks and read-only verification before sign-off
- Upgrade and rollback steps for the UI are written against the versions you deploy
How we support
- Retainers cover patching, upgrades and access reviews for the UI and its integrations
- We review role assignments and audit logs on a schedule agreed in the retainer
- Changes to clusters, identity providers or roles are re-tested in a non-production environment first
- Support boundaries, response expectations and escalation paths are written into the agreement
