DEV Community: Pomerium

Migrating from Ingress NGINX to Pomerium Ingress Controller

Nick Taylor — Sat, 06 Dec 2025 01:57:00 +0000

The Kubernetes community announced that Ingress NGINX will be retired in March 2026. After that, there won't be any more updates, bugfixes, or security patches. While your existing deployments will keep working, running without security updates is risky and there will be no further feature developments.

Many Kubernetes operators are now evaluating alternatives to the community Ingress NGINX controller. The Pomerium ingress controller offers a compelling migration path that provides the same reverse proxy functionality you're used to, with optional zero trust capabilities (what we do best) that you can adopt incrementally without requiring an immediate overhaul of your existing setup.

Why Consider Pomerium?

While there are several good ingress controller alternatives available, the Pomerium ingress controller provides the same reverse proxy functionality you're used to with Ingress NGINX, but with built-in zero trust features that you can adopt incrementally. Since both Pomerium Core and the ingress controller are open source, you can evaluate and implement without vendor lock-in concerns.

Before You Start

This guide assumes you have:

Pomerium installed
The Pomerium Ingress Controller installed
TLS certificates configured (Pomerium requires HTTPS for all routes)
Basic familiarity with Kubernetes ingress resources

What's Different?

Unlike NGINX, Pomerium has two key requirements:

HTTPS is mandatory - all routes must use TLS
Policies are required - you must specify an access policy (even if it's permissive)

These requirements ensure security by default, but you can configure permissive policies that function exactly like traditional reverse proxies.

A Simple Migration Example

Let's look at a typical Ingress NGINX configuration and its Pomerium equivalent:

Ingress NGINX to Pomerium Ingress Controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
+  annotations:
+    ingress.pomerium.io/policy:
+      - allow:
+          any: true
spec:
-  ingressClassName: nginx
+  ingressClassName: pomerium
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-cert

The configuration is nearly identical—just change the ingress class from nginx to pomerium and add a basic policy. The any: true policy tells Pomerium to allow all requests through without applying access restrictions—essentially functioning as a traditional reverse proxy with no additional authentication or authorization layers. Your existing network security, firewall rules, and application-level authentication remain unchanged.

Policy Options for Basic Reverse Proxy Functionality

For straightforward migration that matches Ingress NGINX's default behavior, you have several policy options:

# Option 1: Allow any request (most similar to Ingress NGINX default)
ingress.pomerium.io/policy: |
  - allow:
      any: true

# Option 2: Truly public access (annotation shortcut)
ingress.pomerium.io/allow_public_unauthenticated_access: 'true'

# Option 3: Any authenticated user (if you want basic auth)
ingress.pomerium.io/allow_any_authenticated_user: 'true'

TLS Certificate Management

Since Pomerium requires HTTPS, consider using cert-manager for automatic certificate provisioning. The Pomerium ingress controller integrates seamlessly with cert-manager:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    ingress.pomerium.io/policy: |
      - allow:
          any: true
spec:
  ingressClassName: pomerium
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-cert # cert-manager will create this

Start Simple, Add Zero Trust When Ready

So if you're looking to migrate from Ingress NGINX, migrating to Pomerium gives you immediate reverse proxy functionality identical to Ingress NGINX. Plus, if you decide to explore zero trust down the road, you can replace the permissive policy with fine-grained rules based on user identity, device status, request context, or other factors:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    ingress.pomerium.io/policy: |
      - allow:
          and:
            - domain:
                is: example.com
spec:
  ingressClassName: pomerium
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-cert

Getting Started

With the March 2026 retirement deadline, you have time to plan your migration carefully. The Pomerium ingress controller installation is straightforward and well-documented. You can run both controllers side-by-side during migration, gradually moving services over as you validate functionality.

Whether you're looking for a sustainable long-term solution or preparing for a zero trust future, the Pomerium ingress controller offers a natural evolution from traditional reverse proxy patterns. Start with the familiar, add security when you're ready.

Learn more about the Pomerium ingress controller at github.com/pomerium/ingress-controller or check out the deployment documentation.

Self-Healing File-Based Databroker Without The Postgres Headaches

Nick Taylor — Tue, 04 Nov 2025 15:17:46 +0000

TL;DR We just released Pomerium v0.31 with a new file-based databroker backend. It eliminates the operational overhead of managing a separate data persistence layer by introducing a self-healing, infrastructure-agnostic storage mode that recovers in milliseconds and keeps sessions alive.

Read the full release notes

Scale and Performance Without the Overhead

Few teams have a full-time DBA. And most Pomerium deployments don’t need the control, scale, and complexity of Postgres.

Pomerium’s new file-based databroker backend removes the burden of managing a separate data persistence layer without sacrificing performance.

Meet the Self-Healing File-Based Databroker

The new backend embeds Pebble, the storage engine behind CockRoachDB — a fast, embedded key-value store built for production workloads. It’s designed to cover 80% of real deployments without the overhead of Postgres.

What you get:

Self-healing recovery. Raft handles clustering and leader election. If one node fails, another takes over in less than a second.
Infra-agnostic. Run anywhere — Kubernetes, VMs, bare metal, or air-gapped networks. No managed database required.
Persistent and safe. Sessions and data survive service restarts.
Built for scale. Pomerium’s databroker is optimized for Pebble’s key-value store.
Observability ready. Exposes metrics and traces for direct visibility in Grafana or your preferred tool.

How Self-Healing Works with Optional Clustered Mode

Teams can decide between clustered and non-clustered mode. We recommend clustered mode for teams required self-healing with automatic leader election in the event of a failure.

When cluster mode is active:

The leader writes new data.
Followers replicate changes in real time.
If the leader fails, Raft based leader election promotes a follower to leader immediately.
The new leader already has the full state and resumes writes.

No volume reattachment, or manual replay. Just automatic recovery.

Quick Start Example

Enable file-based clustering with two simple lines:

databroker_storage_type: file
databroker_storage_connection_string: file:///var/pomerium/databroker

That’s it. Your sessions persist. Your data survives restarts. Failover happens automatically.

The Right Default for Most Teams

For most deployments, the file-based databroker is the recommended choice: simple, self-healing, and ready for production.

Pomerium now handles storage the way operators always wanted — quietly, reliably, and without additional operational overhead.

Try Pomerium v0.31

Upgrade to the latest version or deploy fresh today.

Request a demo or connect with your Pomerium team to see how v0.31 simplifies your setup.

NB: Raft is available with Pomerium Core and Enterprise.

Photo by Glen Carrie on Unsplash

Smarter Health Checks for Zero-Downtime Deployments

Nick Taylor — Tue, 21 Oct 2025 17:36:03 +0000

TL;DR

The latest Pomerium release introduces fine-grained and context-aware health checks for Kubernetes, AWS ECS, and systemd. These checks confirm that your routing and policy-enforcement layers are fully ready before handling traffic, giving operators reliable zero-downtime upgrades.

Read the full release notes here

Why Health Checks Matter

Without proper health checks, services can often start before all dependencies are fully ready. Readiness checks should not only confirm network connectivity, but whether you are prepared to handle requests.

The new health checks ensure that all critical components are initialized before traffic is accepted. This ensures smarter startups and improved reliability in automated environments like Kubernetes.

This ensures:

No more “healthy” pods denying requests on startup
Graceful shutdowns that wait for all active connections to drain
Smooth autoscaling and rolling upgrades with zero downtime

Kubernetes: Before and After

Previous behavior

When a new replica started in Kubernetes, it was marked ready immediately. The proxy could receive requests before configuration and policy sync completed. Some requests were denied until initialization finished.

New behavior

Each replica now reports readiness only after it completes startup tasks and verifies configuration sync. Once the new replica signals it is ready, Kubernetes begins draining connections from the old one.

This sequence enables rolling upgrades without downtime or failed requests.

ECS and systemd Support

The new pomerium health command extends readiness logic to AWS ECS and systemd environments.

You can use it to:

Integrate with ECS deployment health checks
Manage service restarts safely under systemd
Maintain uptime during scaling or repaving events

Health reporting works consistently across orchestrators with no special configuration required.

Example Health Check Output

Before Pomerium handles traffic, it confirms that each core service is running:

{
  "authenticate.service": { "status": "RUNNING" },
  "authorize.service": { "status": "RUNNING" },
  "config.databroker.build": { "status": "RUNNING" },
  "databroker.sync.initial": { "status": "RUNNING" },
  "envoy.server": { "status": "RUNNING" },
  "proxy.service": { "status": "RUNNING" },
  "storage.backend": {
    "status": "RUNNING",
    "attributes": [{ "Key": "backend", "Value": "in-memory" }]
  },
  "xds.cluster": { "status": "RUNNING" },
  "xds.listener": { "status": "RUNNING" },
  "xds.route-configuration": { "status": "RUNNING" }
}

Only when all components report RUNNING does Pomerium begin serving requests.

Why You Should Care

These new health checks make Pomerium safer and more predictable during updates and scaling events.

They ensure:

Each replica starts cleanly
Active connections drain fully
Autoscaling and rollouts complete without downtime

Together with improved metrics and file-based databroker storage, this makes Pomerium self-healing and easier to operate in production.

Get Started

Upgrade to Pomerium v0.31 to enable the new health checks automatically in your existing deployments.

For detailed examples and configuration guidance, visit the Health Checks documentation.

Pomerium’s OpenTelemetry Tracing Support: Deeper Observability, Made Easy

Nick Taylor — Thu, 01 May 2025 18:34:51 +0000

Pomerium allows you to securely access Kubernetes APIs, internal apps, databases, and more—without a VPN. But even with faster, direct access, understanding performance issues or request failures in a distributed environment still requires the right observability to trace what’s happening behind the scenes.

That’s why we’re excited to announce Pomerium’s newly improved OpenTelemetry (OTEL) tracing support!

With detailed, contextual tracing, following request flows across Pomerium and your apps just became far easier—and a lot more delightful.

What is OpenTelemetry (OTEL)?

OpenTelemetry is an open-source observability framework that standardizes how applications collect, process, and export telemetry data such as metrics, traces, and logs. It’s the successor to OpenCensus and OpenTracing, and is now the de facto industry standard for modern observability.

Why Move to OTEL?

Previously, Pomerium used OpenCensus for tracing. However, OpenCensus has been deprecated, and upstream projects—including Envoy Proxy—have removed support for it entirely.

If you haven’t run into it before: Pomerium is built on Envoy Proxy, a modern, battle-tested Layer 7 proxy that powers huge production systems at companies like Lyft, Apple, and Shopify.

Key reasons for moving to OpenTelemetry:

Future-proofing: OTLP (OpenTelemetry Protocol) is now the ubiquitous standard across most observability tools.
Deeper tracing: OpenCensus could not trace request flows end-to-end through Pomerium and Envoy.
Better integration: OpenTelemetry support ensures broad compatibility with a wide range of collectors and backends like Jaeger, Tempo, and Honeycomb.

Now, Pomerium’s request tracing flows seamlessly from Envoy into Pomerium’s core services—and you can export it into any OTLP-compatible backend like Jaeger, Tempo, Honeycomb, or others.

Why Are OTEL Traces Important?

Traces capture the full context of a request—from the moment it enters the system to all the internal services it touches.

While logs and metrics show individual points of data, traces show the journey of a request across systems.

As a context- and identity-aware proxy, Pomerium often acts as the critical entrypoint into your distributed systems, especially when handling:

Authentication (OAuth/OIDC flows)
Authorization decisions
Secure routing to protected upstream services

Without proper tracing, debugging complex workflows—like an OAuth login flow that fails after five redirects—becomes guesswork. With tracing, every step becomes visible.

How Pomerium Implements OpenTelemetry Tracing

Pomerium now uses the OpenTelemetry SDK to instrument key parts of its architecture:

Envoy: Ingress traffic and HTTP request handling
Authentication: Identity provider interactions
Authorization: Policy evaluation and enforcement
Proxy: Secure traffic forwarding
Data Broker: Internal service communication
Control Plane: Configuration and service coordination

Even when running Pomerium in "all-in-one" mode, traces are logically separated by component (via service names).

Custom Envoy span naming ensures traces include meaningful names like host, path, and method.

Full End-to-End Tracing Through Envoy

Pomerium’s ability to offer full, detailed tracing starts with its foundation: Envoy Proxy.

By building on Envoy, Pomerium inherits:

Scalability: Envoy is designed for cloud-native, high-volume environments.
Feature richness: Native support for advanced protocols, observability, retries, load balancing, and OTEL tracing.
Reliability: Used in production by companies like Lyft, Apple, and Shopify.

Our close integration with Envoy means your access proxy is future-proofed.

Pomerium didn’t just slap tracing on top. We contributed upstream fixes—like PR #37692—to ensure accuracy and completeness.

Solving Redirects and Sampling in Tracing

Distributed tracing isn’t just plug-and-play—especially when redirects are involved.

Pomerium often handles OAuth flows with 5+ redirects across Identity Providers.

However, HTTP redirects don't carry tracing headers, so traces could become fragmented.

Our Solution

Propagating trace context in query parameters and OAuth state.
Ensuring sampling consistency throughout redirects.
Unified trace view for complex auth flows.

Use Cases for Tracing Pomerium Requests

Real-world examples:

Understand user authentication flows
Debug mysterious authentication failures
Diagnose performance bottlenecks
Analyze network or external system slowness

Each trace provides detailed timing, metadata, and authorization decisions.

Set Up Tracing Today

Tracing isn’t always easy, but we’ve made it as simple as possible with Pomerium v0.29.0.

We can’t wait to hear what you build and what insights you uncover!

Get started today:

Places you can connect with us:

Rethinking Authorization in the Age of AI Agents

Nick Taylor — Fri, 18 Apr 2025 13:56:33 +0000

We’re entering the age of agentic AI — where software agents, not just users, are taking action on our behalf.

With standards like the Model Context Protocol (MCP) are making this more seamless by letting agents access tools and services in a structured, context-aware way. But here's the catch: most existing authorization models weren’t built for this kind of actor.

OAuth, role based access control (RBAC), and traditional session-based models assume a user is behind every request. With agentic systems, intent is often delegated, context can shift dynamically, and agents might act across boundaries we didn’t originally model. Who's responsible? What are they allowed to do? And how do we reason about trust when the actor isn't a person?

We need to start thinking beyond human-centric auth — and my co-worker Bobby’s post, "Agentic Access Is Here. Your Authorization Model Is Probably Broken.", makes a great case for why.

Give it a read and let me know what you think!

Agentic Access Is Here. Your Authorization Model Is Probably Broken. - The New Stack

The new MCP access control model fundamentally can’t measure up to the speed, scope and nondeterminism of AI agent-based access control.

thenewstack.io

Places you can connect with us:

Photo by Igor Omilaev on Unsplash

Pomerium 0.29.0 is Here!

Nick Taylor — Fri, 28 Mar 2025 11:11:46 +0000

We're excited to announce version 0.29.0 of Pomerium. If you haven’t heard of us, we’re a zero-trust identity-aware proxy.

In this release, there's a slick new Routes Portal that shows users exactly what they can access, UDP tunneling for protocols like DNS and VoIP, and HTTP/3 support for faster connections.

We've completely revamped tracing with OpenTelemetry, added direct Azure AD token authentication, and made JWT handling smarter when dealing with large group memberships.

Infrastructure fans: we now have a full Terraform provider for Enterprise!

Check out our announcement post for all the details, and let us know what you think!

Pomerium v0.29.0 | Pomerium

pomerium.com

Places you can connect with us:

Context-Based Access Control and Zero Trust: Key Insights from the CSA White Paper

Eunjee Choi — Thu, 13 Mar 2025 01:35:06 +0000

Introduction

Cloud Security Alliance (CSA)released a white paper on Context-Based Access Control (CBAC) and its role in advancing Zero Trust security models. The paper underscores the necessity of shifting from static, trust-based access control to real-time, adaptive authentication that evaluates risk dynamically, and Pomerium was highlighted as a key player in the CBAC space.
We’ll break down the white paper’s key findings and explore how Pomerium aligns with this modern security framework.

Why Traditional Access Controls Fall Short

Historically, access control has been based on predefined roles and entitlements. The Role-Based Access Control (RBAC) model assigns permissions to roles rather than individual users, simplifying management but failing to adapt to real-time threats. Attribute-Based Access Control (ABAC) improves on RBAC by considering user attributes, but it still lacks dynamic risk assessment and real-time adaptability.
The CSA paper highlights how modern identity-based attacks, such as credential theft and lateral movement, exploit these traditional models. Attackers can obtain valid credentials and operate within an organization undetected, as access decisions are based on static rules rather than continuous evaluation.

What is Context-Based Access Control (CBAC)?

CBAC represents a paradigm shift in access control. Instead of granting access solely based on identity or static attributes, CBAC evaluates real-time contextual signals to determine whether a request should be approved. These signals can include:

User behavior: Is the user accessing resources in a typical pattern?
Device health: Is the device compliant with security policies?
Location & network conditions: Is the request coming from a familiar or risky location?
Time & frequency: Is access being requested at an unusual time or with an abnormal frequency? By continuously analyzing these factors, CBAC minimizes implicit trust and ensures that every access request is assessed based on current risk factors rather than static policies.

Read more about CBAC vs. RBAC vs. ABAC, the CBAC Maturity Model, and Pomerium's role as a zero trust, context-aware access solution on our blog.

What You Need to Know From the 2024 ITRC Data Breach Report

Eunjee Choi — Thu, 27 Feb 2025 00:34:43 +0000

Every year, the Identity Theft Resource Center (ITRC) publishes its Data Breach Report, and every year, the numbers tell a familiar story: breaches are still rampant and personal data is still getting exposed.

The statistics and trends revealed in the ITRC’s 2024’s Data Breach Report help us understand where we are, where things are headed, and—most importantly—what we can do about it.

The Big Picture: 2024 Was a Year of Massive Exposure

If there’s one number you take away from the report, it’s 3,158.

3,158 data compromises were recorded in 2024, just 44 short of the all-time high set in 2023. While the total number of breaches did not increase, the number of victim notices skyrocketed by 312%—meaning the scale of each breach is growing.
In fact, six “mega-breaches” accounted for 85% of all victim notices in 2024.

The Biggest Data Breaches of 2024

Ticketmaster – 560 million victim notices
Advance Auto Parts – 380 million victim notices
Change Healthcare – 190 million victim notices
DemandScience – 121 million victim notices
AT&T – 110 million victim notices

Although these massive incidents were the stars of the show last year, the reality is that thousands of smaller breaches are happening constantly, many of which go unnoticed by the public.

What’s Changing? Key Trends from the Report

1. Companies Won’t Tell Us How They Got Hacked
70% of cyberattack-related breach notices in 2024 failed to disclose how the attack happened—a significant jump from 58% in 2023. This lack of transparency makes it more difficult for other companies to learn and strengthen defenses.

2. Financial Services Overtakes Healthcare as the #1 Target
For the first time since 2018, the Financial Services sector suffered more breaches than Healthcare. Although this could indicate improvements in healthcare security, it’s more likely that there’s been a shift in attacker focus. Banks, insurance providers, and payment processors hold valuable data and may be more vulnerable than the healthcare sector that has endured innumerable attacks in the past years.

3. Credential-Based Attacks Are Still the Top Problem
Four of the six biggest breaches in 2024 were caused by stolen credentials—something that could have been prevented through Multi-Factor Authentication (MFA) and passkeys. According to the report, 94% of all devices now support passkeys, but adoption is slow, and companies continue to rely on passwords that attackers can guess or steal.

4. AI is Helping Hackers—But Also Defenders
While no breaches were officially attributed to AI-powered attacks, it’s clear that AI is being used to enhance phishing attempts, automate attacks, and find vulnerabilities faster than ever. At the same time, AI-powered security tools are improving at detecting threats, creating an ongoing arms race between attackers and defenders.

Read more on the historical context, what needs to change, and the importance of Zero Trust security models on our blog.

What is Zero Trust Security?

Nick Taylor — Fri, 07 Feb 2025 02:21:08 +0000

What is zero trust? I like to use an airport analogy to convey the concept.

Think about airport security. Traditional perimeter-based security, like a virtual private network (VPN), is like showing your ID to security, not your bags or anything else, and then you're in never to be checked again. You could walk to a gate and say you're the pilot. Not great, right?

Zero Trust security takes a different approach - more like how airports actually work. No boarding pass? You'll need to verify who you are at the ticket counter first. Got your pass? Great, but it isn't a free pass to wander - it only works for your specific flight, at your specific gate, at the right time. This matches how an identity aware proxy works in Zero Trust security.

Let's take a look at a real world situation, production access. Just because you're an engineer doesn't mean you get 24/7 access to production. You might only get elevated permissions during your on-call shifts. So the context here isn't just who you are, but when you're allowed to access a resource.

Here's the big difference: old-school perimeter security is binary - you're either in or out. Zero Trust keeps asking:

Are you who you claim to be?
Are you where you're supposed to be?
Is this the right time for your access?
Does your current context justify this access level?

Zero Trust doesn't mean no trust - it's about being precise with access. Right person, right access, right time, right context.

Context matters and always be verifying.

Places you can connect with us:

Photo by Icarus Chu on Unsplash