gnana997/periscope

Periscope is a self-hosted web dashboard for managing Kubernetes clusters across an organisation, with a particular focus on clusters running on Amazon's EKS service. Kubernetes is the system that runs containerised applications across a fleet of machines, an admin usually pokes at it through the kubectl command-line tool. Periscope gives that admin a single browser page that talks to every cluster they have, showing pods, deployments, logs, events, and the like, with a Slack-style left rail to switch between clusters. The main selling point in the README is how it handles credentials. Many existing tools require a long-lived AWS key sitting on the dashboard server, which is hard to justify under modern compliance rules. Periscope avoids this by using AWS's Pod Identity or IRSA, which hand out short-lived cluster access on demand, so there is nothing static to steal from the console pod. Users log in through OIDC (a standard sign-in protocol, the author has tested Auth0 and Okta), and every action they take inside Kubernetes is performed as their own identity through a feature called impersonation. The result is that audit log rows show real names like alice@corp instead of a generic service account. The audit log itself is stored in a small SQLite database, searchable and filterable inside the app, with retention limits, which the README pitches as a way to make compliance reviews faster than grepping raw log files. Resource list pages stream live updates over Server-Sent Events (a one-way HTTP push channel) for 21 different resource types, with a polling fallback for corporate proxies that block streaming. The built-in YAML editor knows the schema for standard Kubernetes objects and Custom Resources, applies changes through server-side apply, and detects drift while you type. Version 1.1, released in mid-May 2026, adds an AWS Access section that catalogues IAM entries, service-account-to-role mappings, and lets you ask the reverse question of which workloads can perform a given action. Clusters outside EKS can be added through a small agent that runs inside any cluster with outbound HTTPS, including GKE, AKS, and on-prem k3s, without needing AWS trust to be set up. Installation is via a Helm chart, with a kind-based local demo profile for trying it out in a minute.