Introducing Truster: authenticate users and services to your apps or Kubernetes clusters

TL;DR

With the release of version 2, Easy OIDC has been renamed to Truster: a small, self-hosted OIDC provider for authenticating users and services to your applications or Kubernetes clusters.
Users can sign in with Google, GitHub, another OAuth2/OIDC provider, or a one-time code sent by email. Truster never stores user passwords.
Services such as GitHub Actions and Buildkite jobs can exchange their existing OIDC tokens for scoped Truster identities using explicit trust policies.
Version 2 adds modern application authentication features including DPoP, Pushed Authorization Requests, rotating refresh tokens, and revocation, while continuing to require PKCE for every authorization flow.
Every release includes a multi-architecture OCI image and OCI Helm chart, alongside official OpenTofu/Terraform modules for AWS and Google Cloud.
Please show your support by starring the Truster GitHub repository!

Today marks the release of Truster v2.0, an Apache 2.0 licensed OIDC provider for authenticating users and services to your applications or Kubernetes clusters.

Truster is the new name for Easy OIDC, which first launched in November 2025. This isn’t just a rename. Easy OIDC began as a straightforward way to authenticate people to Kubernetes with their existing Google or GitHub accounts. It remains straightforward to run, but version 2 has grown into a much more complete OIDC solution for applications as well as clusters, and for services as well as people.

The old name no longer represented what the project had become. “Truster” better describes its role: establishing explicit trust between identity providers, people, services, applications, and Kubernetes clusters.

One issuer for people and services

Truster sits between the system that proves an identity and the application or cluster that uses it.

It authenticates an identity, applies your policy, and issues short-lived signed tokens.

Your application remains responsible for its own authorization, just as Kubernetes RBAC remains responsible for deciding what a user or group may do inside a cluster.

Version 2 expands both sides of that model.

Truster supports multiple sign-in methods behind one issuer URL.

People can authenticate with Google, GitHub, a generic OAuth2/OIDC provider, or a one-time code sent by email. Multiple connectors of the same type are supported too, which is useful when an organisation needs to trust more than one upstream OIDC provider.

The new direct email flow means an upstream identity provider is optional. Truster sends a short-lived, single-use eight-digit code over SMTP and verifies it without creating a local password.

Email verification can also be applied to identities received from an upstream provider: trust the provider’s verified email assertion, verify only when needed, or always require a local code.

Whichever sign-in method a person uses, Truster normalises their verified email into a consistent downstream identity. You can then map that identity to groups for an application or Kubernetes RBAC.

OIDC federation for agents, CI, and automation

People aren’t the only identities that need access. AI Agents, CI jobs, and automation needs credentials too, and long-lived secrets are a poor way to provide them.

Truster v2 supports external OIDC trust and token exchange. You can define an issuer, a reusable trust policy, and a client-specific binding that describes exactly which external identities should be accepted. Truster includes presets for GitHub Actions and Buildkite, and can federate with any compatible OIDC issuer.

For example, a policy can require an immutable GitHub organisation ID, then a binding can narrow that trust to one repository, environment, and reusable workflow. If exactly one binding matches, Truster exchanges the external token for a short-lived identity and the least-privilege groups you configured. If the policy is missing, ambiguous, invalid, or unavailable, Truster fails closed.

This gives your services the same clear trust boundary as your users, without distributing another static credential to every job or agent.

Built for application auth, not just Kubernetes

Easy OIDC was designed primarily around kubectl and Kubernetes control plane authentication. Truster still supports that use case, but version 2 is also designed to act as the OIDC provider for your own applications, including SaaS applications.

The new application integration guide covers three practical architectures: a same-site SPA and API using HttpOnly token cookies and a browser-held DPoP key, a direct SPA using DPoP, and a backend for frontend. It includes the complete login, token validation, refresh, revocation, session, CSRF, and key-lifecycle requirements, rather than just the happy path of redirecting to a login page.

Version 2 adds the protocol support needed for those integrations:

DPoP-bound access and refresh tokens make a copied token insufficient on its own. The client must also prove possession of its private key for every protected request.
Pushed Authorization Requests (PAR) let clients send protected authorization details directly to Truster before redirecting the browser.
Rotating refresh tokens and grant revocation support longer-lived sessions without treating a refresh token as an unchanging secret.
Separate access and ID tokens have independently configurable lifetimes and clearly defined purposes for applications and Kubernetes.

These features are opt-in where different clients need different security and compatibility trade-offs. PKCE with S256 is not: Truster continues to require it for every authorization code flow, does not support downstream client secrets, and provides no fallback to a less secure non-PKCE flow.

Policy as configuration or queried when needed

The original Easy OIDC model was deliberately simple: define clients and map email addresses to groups in a JSONC configuration file. That remains the default and is still a great fit when policy belongs in Git, where every change can be reviewed and audited.

Truster v2 also supports an optional, read-only PostgreSQL policy database. This allows clients, user access, user-to-group mappings, and external OIDC trust bindings to be queried on-demand. It’s useful when policy already lives in an application database, needs to change without restarting Truster, or is too dynamic to manage in a deployed configuration file.

Truster never writes to the policy database. Your application or operational system remains responsible for managing that data, and Truster connects with a dedicated read-only role. Static policy and database policy can coexist, with static clients taking explicit precedence.

Scale from one binary to multiple replicas

Truster still has a small operational footprint. The simplest deployment is one binary using its embedded SQLite state database, and that remains the default. There is no requirement to deploy PostgreSQL just to get started.

When higher availability or horizontal scaling is required, protocol state can be stored in PostgreSQL. Multiple Truster replicas can share browser login state, authorization codes, one-time codes, refresh grants, and revocations. The state database is separate from the optional policy database: one stores the operational state Truster writes, while the other supplies policy that Truster only reads.

Version 2 includes database migrations, readiness checks, atomic single-use state consumption, and separate runtime and migration credentials. This keeps the one-process deployment straightforward while providing a clear path to a multi-replica deployment when it is actually needed.

Deploy to the container platform of your choice

Truster is no longer limited to the single-VM deployment model. Every release publishes a Linux AMD64 and ARM64 OCI image at ghcr.io/truster-dev/truster, plus an OCI Helm chart at ghcr.io/truster-dev/charts/truster.

The Helm chart runs one replica with persistent SQLite by default. Configure a PostgreSQL state database when you are ready to scale horizontally. The chart supports Ingress, cert-manager or an existing certificate for native backend TLS, externally mounted secrets with the Secrets Store CSI Driver, and isolated migration credentials. Its Pod runs as a non-root user, drops Linux capabilities, uses a read-only root filesystem, and does not mount a Kubernetes API token by default.

Official OpenTofu/Terraform modules remain available for a low-cost VM-based deployment across both AWS and Google Cloud.

Truster can also serve HTTPS directly and read secrets from files, making it straightforward to integrate with the certificate and secret management already provided by your platform.

Release artifacts, container images, and Helm charts are signed and published with SBOMs and build provenance.

All user-facing pages and emails use embedded templates. You can override only the templates you want to change by mounting a directory into the container. There is no need to fork the project or rebuild the binary.

Overrides cover the shared page layout, sign-in selector, identity selection, email-code form, error page, and both HTML and plain-text email content and subjects. Truster parses and test-renders the effective template set at startup, so an invalid template prevents a broken deployment from serving traffic.

For local iteration, the new truster dev command serves every page and email template with mock data and live reload. Configuration and template checks can also run independently in CI:

truster check config --config ./config.jsonc
truster check templates --config ./config.jsonc

Try a complete flow locally

Truster v2 includes a self-contained demo mode, so you can try the complete email-code sign-in flow without configuring a cloud account, domain, signing key, or upstream identity provider.

Install and run Mailpit locally:

brew install axllent/apps/mailpit
mailpit

With Go installed, in a new terminal, run the Truster demo server:

go run github.com/truster-dev/truster/v2/cmd/truster@latest serve --demo

Truster generates temporary secrets and an ephemeral SQLite database.

Start a login with kubelogin in a new terminal, enter any email address, and copy the code captured by Mailpit back into the browser:

kubectl oidc-login get-token \
  --oidc-issuer-url=http://localhost:8080 \
  --oidc-client-id=kubelogin-local \
  --grant-type=authcode \
  --listen-address=127.0.0.1:8000

Everything generated by demo mode is removed when the process exits.

Still secure and straightforward by default

Truster stores no user passwords. It uses short-lived, asymmetrically signed tokens. Authorization codes and email codes are opaque, expiring, single-use, and atomically consumed. PKCE S256 is mandatory. Configuration, secrets, database connectivity, and templates are validated before the server accepts traffic. Policy failures deny access rather than falling back to stale or incomplete decisions.

You can run one small binary with SQLite and policy in a file, or adopt PostgreSQL, dynamic policy, multiple replicas, DPoP, and federation as your requirements grow. Complexity is available where it solves a real problem, but it isn’t imposed on the smallest deployment.

That is ultimately why Easy OIDC became Truster: it is still an easy way to add OIDC authentication to Kubernetes, but it has become much more than that.

Please ⭐ star the Truster GitHub repository to show your support.

Truster is an Open Source subproject of Podplane - so if you have questions or want to discuss Truster, please join the Podplane Community Forum.

Thanks for reading!

Published: Aug 13, 2026 .