Pomerium v0.23 Announcement
Pomerium v0.23 is here! This version brings improved Observability capabilities and mTLS settings, followed by major performance improvements and bug fixes. All of the changes apply to Pomerium Core!
Downloads are immediately available on Github Releases, and Dockerhub for all supported platforms.
Observability — Better Auditing and Logging!
Pomerium v0.23 introduces two new Access Log Fields and Authorize Log Fields settings, which allow you to customize, find, and review HTTP request logs from Pomerium services.
Previously, Pomerium users needed to follow strict steps in Audit Logs to retrieve logs from a specific Pomerium service. These new enhanced logging configurations make it easier to find and review HTTP request logs from Pomerium services, allowing you to log ID tokens, custom request headers, and even the request query parameters.
For more information and examples, please see the Logging Configurations section of the upgrading guide.
New Downstream mTLS Settings
In v0.23, you get more control over how you handle client certificates with the new downstream mTLS settings. The main highlight is a new Enforcement Mode setting, which allows you to choose Pomerium’s behavior when a client does not present a trusted certificate.
This setting is for teams who want to ensure client certificates are verified before policy evaluations are made. When this option is set to the new reject_connection mode, any attempts to connect without a trusted certificate will be rejected during the TLS handshake. This allows you to configure mTLS as an isolated security layer, entirely independent from Pomerium policy evaluation. See the reference details for some important considerations before enabling this mode.
We’ve preserved the behavior of previous Pomerium releases in default mode: if a client attempts to connect without a trusted certificate, Pomerium will still accept the connection in order to serve an HTML error page.
Additional options allow you to customize which client certificates will be trusted:
- CRLs can be used to revoke individual certificates (beta)
- Max Verify Depth can be used to allow intermediate CA certificates
- Match Subject Alt Names can be used to require that certificates contain a SAN matching a particular regular expression
This new suite of mTLS settings replaces previous certificate-related options (like Client CRL and Client Certificate Authority) and introduces new options all in a single downstream_mtls key.
See the Downstream mTLS Settings page to view the new options and examples.
New Set Request Headers Options
The Set Request Headers setting now supports a number of dynamic token substitutions for passing token:
- ${pomerium.id_token}
- ${pomerium.access_token}
- ${pomerium.client_cert_fingerprint}
The first two allow you to pass IdP tokens directly to an upstream service. Currently, the existing Set Authorization Header option only allows you to do this in the Authorization header. These two new tokens can be passed in any header, allowing you to use the Authorization header for other purposes.
The third option allows you to forward the SHA-256 client certificate fingerprint from a downstream mTLS service to an upstream service. This is for upstream services that want to make additional authentication decisions with this information.
Note: If you have an existing custom header value that includes the $ character, you may need to replace it with $$ to avoid being treated as a variable substitution.
New PPL Criteria: Certificate Matcher (beta)
In v23, we’ve added new client Certificate Matcher criteria to PPL. Now, you can build policies that make access control decisions based on the client certificate’s fingerprint or Subject Public Key Info (SPKI) hash.
This will allow organizations to tie a device identity and state to a user for better security posture. While WebAuthN can provide device identity for device registration, often a shared stable identifier is required to associate device state. The feature addresses this by tying device identity, state, and user identity through client certificates. If the fingerprint or SPKI hash aren’t valid based on your policy, Pomerium will deny the client access – even if the user authenticated against your Identity Provider.
Various Performance Improvements and Bug Fixes
You can now also configure Cookie SameSite in the Console. We’ve also made other improvements and bug fixes that can be found in the full changelog!
Next Steps
We always recommend testing new releases in a separate environment before fully implementing them, and of course, always to back up your database. If you run into any issues, don’t hesitate to let us know by submitting a report on the Pomerium GitHub issue tracker.
Securing Web Applications
Pomerium is purpose-built for companies moving from perimeter to zero trust and identity-based access. We are proud to support these companies with features and capabilities built specifically for their needs. To learn how Pomerium can support your organization’s needs, checkout our Github, documentation, or reach out to us directly.
