Paralus: a Kubernetes access layer for people who are not Kubernetes users
All-in-one Kubernetes access manager. User-level credentials, RBAC, SSO, audit logs.
At a glance
- What is it?
- Paralus is a CNCF Sandbox project that puts an access management layer in front of Kubernetes, issuing short-lived credentials on request from an identity provider, applying role policy across clusters and namespaces, and logging every user action. The interesting architecture is visible in its compose file: Postgres, Ory Kratos for identity, and a migration step that has to succeed before the server starts.
- Who is it for?
- Paralus fits a platform team that has to give a growing set of internal users and services controlled access to many Kubernetes clusters without writing RBAC by hand for each of them. It does not fit a single-cluster setup with a handful of administrators, and it does not fit a team that cannot accept an identity service and a policy database in its architecture.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 129 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The user is not always a person with a kubeconfig
Paralus is described as a free, open source tool that enables controlled, audited access to Kubernetes infrastructure for your users, user groups, and services, and it ships as a GUI, an API and a CLI. It is a CNCF Sandbox project.
The phrase that carries the design is users, user groups, and services. Kubernetes' own access model is built around subjects that are usually people with long-lived credentials, and it is not built for a service asking for a short-lived token as part of a pipeline. Paralus exists to sit in front of that model and provide an access layer for identities that come from outside the cluster's own user store.
The integration story is what makes it adoptable. Paralus can be integrated with your pre-existing RBAC configuration and your SSO providers, or Identity Providers that support OIDC, and the feature list names the familiar set, GitHub, Google, Azure AD and Okta among others, for both user authentication and group definitions. That last part matters: a group coming from the identity provider is a group the platform does not have to maintain, and it is the difference between an access layer that is a second source of truth and one that is a front end for the source of truth you already have.
The audience is a platform or security team, and the problem being solved is one of scale and accountability rather than of raw capability.
Just-in-time credentials, with revocation as the product
Two mechanisms do the work, and the feature list names them: just-in-time service account creation and fine-grained user credential management.
Just-in-time creation is the part that changes the model. Instead of a user holding a credential that is valid until somebody remembers to remove it, a service account is created when it is needed and the credential is issued at that moment. The consequence is that access has an end, and a credential that leaks is a credential that stops working.
The second half of the list is where the operations story is. There is dynamic and immediate changing and revoking of permissions, and the ability to control access via pre-configured roles across clusters, namespaces, projects and more. The phrase immediate is doing the work, and it is what the README means by rapidly identify and respond to threats through dynamic permission revocation.
On top of that sits the accountability layer, with automatic logging of all user actions performed for audit and compliance purposes. Combined with just-in-time credentials, the two features answer different questions. The credentials answer how long someone had access. The audit log answers what they did with it. Neither substitutes for the other, and a project that only had the second would be a logging tool, while a project that only had the first would still leave a gap.
There is also a role and group model on top, with creation of custom roles, users and groups, so the policy is something you administer rather than something the identity provider dictates.
Three ways in, and an identity service you have to run
Paralus can be driven from a modern web GUI, which the README marks as the default, from a CLI tool called pctl, or through the Paralus API. Three surfaces over one control plane is a deliberate choice, because the API is what a script or a pipeline uses, the CLI is what a human uses during an incident, and the GUI is what an administrator uses when onboarding somebody.
The dependency list in go.mod shows the identity story in detail. There is ory/kratos-client-go, which is the client for Ory Kratos, and Kratos is an identity service that handles users, sessions and credentials. There is crewjam/saml for SAML, in addition to the OIDC support, so an organisation whose identity provider speaks SAML rather than OIDC is not excluded. There is casbin with its gorm adapter, and there is uptrace/bun for the database layer, with pgdriver and a gorm postgres driver alongside it.
The Kubernetes side is client-go, and here there is a detail worth noticing. The k8s.io/api, apiextensions-apiserver, apimachinery and client-go dependencies are all pinned at version 0.23.4, while the module declares go 1.25.5. A Kubernetes client library that old talking to a current cluster is the kind of combination you want to check against the API versions you actually have enabled, and it is a reasonable question to raise with the maintainers before an upgrade.
The design intent, then, is a platform that owns identity and policy and delegates the cluster to Kubernetes. That is the right split for the problem, and it is also why the component count is what it is.
The compose file is a dependency graph, and it is a development one
The repository's docker-compose.yml is the most informative document in the project, because it shows the order in which things have to come up.
The first service is postgresd, an image of postgres:14.2, with its credentials coming from environment variables and its data on a named volume. Then kratos-migrate, an image of oryd/kratos, which depends on the database and runs the command migrate sql -e --yes against a configuration bind-mounted from the _kratos directory, with restart set to on-failure. Then migrate-admindb, which depends on kratos-migrate with the condition service_completed_successfully, and runs the migrate/migrate image against the migrations in the persistence directory.
Only after that does the kratos service itself start, with a public port and an admin port, the same DSN, and a command that serves with --dev --watch-courier. A mailslurper service sits alongside it to catch the emails Kratos sends.
Read that ordering as a statement about the system. There are two databases to prepare, an identity service whose schema must be migrated before it will serve, and the application database on top. A deployment that gets the order wrong does not start, which is the friendly kind of failure.
But read the flags as well, and it is clear this file is a development harness. Kratos is running with --dev, the log level is trace, the DSNs carry sslmode=disable, and a mail catcher is receiving the messages a production deployment would deliver. The README points to the Installation page on the documentation site for the real procedure, and that is the file to follow for anything beyond a trial.
Three exposed ports and a static binary
The Dockerfile is short and gives you the shape of the deployment.
The build stage is golang:1.25.5 with CGO_ENABLED set to 0, so the result is a static binary with no libc dependency, and the make build target produces it. The runtime stage is alpine:latest and copies the binary to /usr/bin/paralus.
Three ports are exposed, and each is a different kind of traffic. 10000 is the RPC port, 11000 is the HTTP port, and 10001 is the RPC relay peering port. The third one is the one to understand rather than ignore, because a relay that peers with other nodes is a component that has to be reachable for the system to work as designed, and a deployment that exposes it carelessly has done something with the trust boundary that the operator did not intend.
The Makefile is conventional and tells you the workflow. tidy and vendor handle dependencies, build compiles with the symbol table and debug information omitted to reduce the size of the binary, test runs go test across the tree, check runs go fmt and go vet, and build-proto uses buf to build and generate the protobuf code from the proto directory, with a clean-proto target that removes the generated files first. The changelog target runs conventional-changelog over the commit history, which is how the CHANGELOG.md at the root stays generated rather than written.
There is also a Dockerfile.initialize and a Dockerfile.synchronizer, and a _filebeat directory, which suggests the components that reconcile what Paralus believes about access with what the clusters actually contain, plus a way to ship those logs out.
Sandbox status, Apache-2.0, and a version 0.3.0
The licence is Apache-2.0, with the LICENSE file in the repository and the licence badge pointing at it. The project carries the CNCF Sandbox designation, which is a specific statement about maturity: it is a project accepted into the foundation's incubation path, not one that has graduated.
The release history is worth reading carefully. Version 0.2.8 was published on 2024-06-14, 0.2.9 on 2025-05-23 and 0.3.0 on 2026-01-16, and the last push to the repository was on 2026-06-16. So the project has moved through three minor versions over about two years, with the most recent release at the start of 2026 and work continuing afterwards.
That shape is consistent with an infrastructure project that changes in a small number of significant ways rather than continuously. The 0.x version number is the honest signal that the API is not frozen, and anyone embedding Paralus in a pipeline should pin a version and read the changelog, which the Makefile generates from conventional commits.
The project runs a community meeting on the second and fourth Tuesday of every month, with the time given in three zones, and it publishes an ics file in the repository so people can subscribe. Participation is governed by the CNCF code of conduct, the maintainers are listed in MAINTAINERS.md, and the project is maintained and supported by Rafay. The repository also holds ROADMAP.md, ADOPTERS.md and GOVERNANCE.md, which are the files to read when you want to know where the project is going rather than what it does today.
Editorial conclusion
Paralus fits a platform team that has to give a growing set of internal users and services controlled access to many Kubernetes clusters without writing RBAC by hand for each of them. It does not fit a single-cluster setup with a handful of administrators, and it does not fit a team that cannot accept an identity service and a policy database in its architecture. Before you deploy, read the Installation page, and treat the repository's compose file as a development harness rather than a production deployment, since it runs Kratos in dev mode with a mail catcher.
Frequently asked questions
What does Paralus do for a Kubernetes cluster?
It provides controlled, audited access to Kubernetes infrastructure for users, user groups and services, through just-in-time service account creation and fine-grained user credential management, with dynamic permission revocation and automatic logging of all user actions.
Which identity providers can Paralus use?
Paralus integrates with SSO providers and Identity Providers that support OIDC, with GitHub, Google, Azure AD and Okta named, and it also depends on crewjam/saml for SAML support. The identity definitions can supply both users and groups.
How do you interact with Paralus?
Through a modern web GUI, which is the default, through a CLI tool called pctl, or through the Paralus API.
What services does Paralus need to run?
The repository's compose file starts Postgres, then runs the Kratos identity migration, then the admin database migration, and only then the Kratos service itself, with a mail catcher for local development. The application binary exposes an RPC port, an HTTP port and an RPC relay peering port.
What licence is Paralus released under and what is its project status?
It is released under the Apache 2.0 licence, and it is a CNCF Sandbox project. The recent releases are v0.2.8 from 2024-06-14, v0.2.9 from 2025-05-23 and v0.3.0 from 2026-01-16.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/paralus-paralus)Was this useful?