Security and audit at Kubepier

Where to allow the IPs

Each service has its own list of authorized IPs. Add the Kubepier IPs next to the ones from your own networks (office, VPN, CI) that are already there.

Commands for AKS, EKS and GKE

Replace <ip-1>, <ip-2> with the IPs listed above and <already-allowed-ips> with the ones the cluster already accepts:

# AKS
az aks update -g <resource-group> -n <cluster> \
  --api-server-authorized-ip-ranges <ip-1>/32,<ip-2>/32,<already-allowed-ips>

# EKS
aws eks update-cluster-config --name <cluster> \
  --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="<ip-1>/32,<ip-2>/32,<already-allowed-ips>"

# GKE
gcloud container clusters update <cluster> --enable-master-authorized-networks \
  --master-authorized-networks <ip-1>/32,<ip-2>/32,<already-allowed-ips>

These commands replace the current list. Include the IPs that are already allowed, or you cut off whoever already uses the cluster.

What a fixed IP guarantees, and what it does not

• The cluster API and the services stop answering the whole internet: only your networks and Kubepier.
• The IPs are shared by every Kubepier Web customer. The IP allowlist is a network layer on top of credentials, never a replacement: whoever arrives from Kubepier’s IPs still needs the token, certificate or password.
• Use least-privilege credentials. Each documentation page says which permission each feature needs.
• Fully private endpoints (no public endpoint, VPC-only or behind a VPN) cannot be reached by the Direct route. For those, use the Through the cluster route (a restricted relay in one of the client’s clusters, opening nothing to the internet) or Kubepier Desktop over your VPN.

• Network and egress IPs, step by step
• Build a read-only kubeconfig
• Connecting services: public and private networks

Encrypted credentials

• On the web, cluster tokens and certificates, Azure and AWS account secrets and each client service’s whole access (RabbitMQ, Service Bus, MongoDB and Redis) are encrypted with AES-256-GCM before reaching the database. The encryption key lives outside the database.
• Once saved, credentials never come back to the screen or the browser: the server is what queries the services.
• On desktop, access to client services is encrypted by the OS keychain (Keychain, DPAPI or libsecret). Without a keychain, nothing is written to disk and the access lasts until the app closes.
• On the web, a Secret shows only its keys and the size of each value, never the values, which is why it cannot be edited from the web.
• The database runs on Microsoft Azure, in the Brazil South region, and traffic uses TLS.

• Data privacy

GitHub sign-in, no new password

• Kubepier Web has no password of its own: you sign in with your GitHub account, and the session lives in a cookie.
• The desktop app signs in with the same account: it shows a code, you approve it in the browser and it gets a token of its own, encrypted by the OS keychain. Without a keychain, the token is not written to disk and the status bar says the sign-in lasts until the app closes.
• You can see and disconnect every device at app.kubepier.com.br/desktop.

Roles and per-client access

• Everyone in the organization is either an admin or a member (a team with members only exists on Team). There is one rule, on the web and on desktop (on desktop, from version 2.7.0): admins do everything the plan allows, typing the name on destructive actions, and members only read.
• Admins see every client, add clusters and credentials, invite the team and, on a paid plan, edit, scale, restart, delete, open a pod or node shell, purge queues and edit Redis keys.
• Members are read-only. On the web, they only see the clients granted to them (per-client access only exists on the web). On a paid plan, they also get live logs, message peeking, the MongoDB panel and the Redis key browser. Anything not granted answers as if it did not exist.
• In the audit log, admins see the whole organization and members see their own entries, on the clients granted to them; both export CSV on a paid plan. On Free, each person sees a preview of their own entries from the last 7 days, without CSV.
• Invites are valid for 7 days. Whoever leaves the team loses web access right away; on desktop, they keep the paid features until the licence is checked again, within 6 hours.

• Team and permissions
• Audit log

Free is read-only

On the Free plan, on the web and on desktop, you can connect the production cluster and explore it with no risk of changing anything: edit, scale, restart, delete, live logs, shell, message peeking, actions on client services and AI diagnosis are on the paid plans. The desktop app only opens after you sign in, and the organization’s plan applies there too. From 2.7.0, the desktop app checks the plan in its main process, and Free also locks the local terminal, creating resources, Helm (install, upgrade, rollback and uninstall) and the Lens Metrics installer.

Audit: who changed what, and confirmation on destructive actions

• On the web, restart asks for confirmation and delete asks you to type the resource name. On desktop 2.7.0, delete, force, finalize, drain, node shell and uninstalling a Helm release also ask for the typed name and are admin-only. Every attempt to edit, scale, restart or delete from the web goes to the audit log, with who did it, when, on which cluster and resource, and whether it worked.
• Purging a queue or its DLQ asks you to type the queue name. Deleting a Redis key asks for confirmation, and deleting several asks you to type the count. There are rate limits (5 purges every 10 minutes, 20 keys deleted per minute), and this is admin-only (on desktop, from 2.7.0).
• Purges and edits on services go to the database audit log on the web and to the local kubepier-audit.log file on desktop: who, when, which client and which names. Never the content.
• Every shell session goes to the audit log (web) or to kubepier-audit.log (desktop), with the target. On desktop, cluster actions too: apply, edit, scale, restart, delete, cordon, uncordon and drain and, from 2.7.0, Helm (install, upgrade, rollback and uninstall), port-forward and the local terminal. The web shell is admin-only, lasts at most 2 hours and each person can have up to 3 open at once. The web node shell asks the admin to type the node name to confirm, and its temporary pod is deleted when the terminal closes.
• The shell checks the connection origin: another site cannot open a shell with your session.
• On the web, the Audit log screen filters by period, user, client, cluster, action and result and exports CSV. On desktop, the same lives in Preferences › TR › Audit, read from kubepier-audit.log.

• Audit log: what is recorded and who sees it
• Quick reference: every limit

What is never stored

• The content of resources, logs and shell sessions: it passes through the screen while it is open and is not recorded.
• Queue message bodies and Redis key values: they show on screen when you open them and are never stored, cached nor written to server logs.
• In MongoDB slow operations and the Redis SLOWLOG, filter and command values are replaced with "?" or reduced to a count.
• The audit log records who did what and where, never the content.

• Data privacy

AI diagnosis: what leaves and where it goes

AI diagnosis sends the provider the pod context, always after removing private keys, tokens, cloud keys, passwords, credentials in URLs, e-mail addresses, IP addresses and long strings that look like secrets. It sends the status of the pod and each container and the names of the environment variables, never the values; Secrets and the kubeconfig never go. Events and logs add up to 16 KB at most.

Kubepier neither stores nor logs the text sent or the answer. The audit log only records who asked, when, on which cluster and pod, and during the trial it marks the trial key and the origin (web or desktop). During the trial, each user can run up to 30 diagnoses a day (São Paulo time, web and desktop combined), there is a monthly quota shared by all users, and a Pro or Team organization with its own key uses it without using up the trial. Free has no AI diagnosis. The history on the AI analyses screen stays only in the browser or, on desktop 2.7.0, on the computer of whoever asked.

• AI diagnosis
• Privacy policy

Kubepier Desktop connects from your machine

• The desktop app uses your kubeconfig and talks straight to the cluster APIs and the client services, through your network or VPN, including exec plugins such as kubelogin, aws and gke-gcloud-auth-plugin. That traffic does not go through Kubepier’s servers.
• The account applies the plan: the app checks the licence with the server. Without internet, an already confirmed Pro or Team licence stays valid until the date the server set (7 days after the last check), for every paid feature.
• Desktop usage records carry only app start, minutes of use, sign-in, version and operating system. The format the server accepts has no field for cluster names, namespaces, kubeconfig or content.
• AI diagnosis with your own key goes straight from your machine to the provider. From 2.7.0, during the 7-day trial or with the organization’s key, it goes through the Kubepier API. The full flow is in the AI diagnosis section above.

Nothing installed in the cluster

Kubepier talks to the Kubernetes API and installs no agent. The exceptions are requested by you: Lens Metrics (desktop), to see usage: under the cluster Settings › Metrics, the Install / Update button applies Prometheus, kube-state-metrics and node-exporter in the lens-metrics namespace, and Uninstall deletes that namespace after you confirm, and temporary pods that go away when the feature ends.

• Node shell (web and desktop): a privileged pod in kube-system, pinned to the chosen node, deleted when the terminal closes. On the web, the kubepier-shell-no-* pod uses an image pinned by digest, has no service account token and is also deleted on error, on a dropped connection, after 120 s without starting or after 2 hours. If the cluster blocks privileged pods (Pod Security, Azure Policy, Gatekeeper, Kyverno), the node shell does not open.
• Secure tunnel (desktop): for a host in the cluster network, an unprivileged relay pod, deleted with the last tunnel, at 2 hours or when the app quits.
• Bastion (web): an unprivileged pod in the chosen namespace, deleted on close or at 2 hours.
• Route through the cluster (web): an unprivileged relay in the route’s cluster and namespace, deleted after 10 minutes idle or at 2 hours.

Bastion and Secure tunnel, unprivileged

• Bastion (web): a temporary pod in the client namespace with the PodSecurity "restricted" profile (user 1000, no capabilities, read-only root, memory-backed HOME and /tmp, no ServiceAccount token), image pinned by digest. It lasts at most 2 hours and is deleted on close. The optional SSH key lives only in the pod’s memory.
• Secure tunnel (desktop): the connection starts on your machine. For a Service, it is a direct port-forward, no pod. For a host in the cluster network, a restricted relay pod (socat only, no interactive access) is created and deleted with the last tunnel, at 2 hours or when the app quits. The local port only listens on 127.0.0.1.
• Open, close and tunnels go to the audit log; content never does.

• Bastion (web)
• Secure tunnel (desktop)

Privacy and LGPD

Personal data is handled under Brazil’s LGPD and described in the privacy policy: what we collect, why, who we share it with and how long we keep it.

• Privacy policy
• Terms of use
• Data privacy