- DATE:
- AUTHOR:
- Ory Team
Ory Hydra, Ory Kratos, Ory Keto, Ory Oathkeeper, Ory Polis v26.4.1 released
Ory Hydra
FIPS 140-3 container images and Helm chart support for Kratos, Hydra, and Polis
Every Ory Enterprise License release now publishes FIPS 140-3 images of Ory Kratos, Ory Hydra, and Ory Polis next to the standard images, with the same tags:
europe-docker.pkg.dev/ory-artifacts/ory-enterprise-kratos/kratos-oel-fipseurope-docker.pkg.dev/ory-artifacts/ory-enterprise/hydra-oel-fips, also onus-docker.pkg.deveurope-docker.pkg.dev/ory-artifacts/ory-enterprise-polis/polis-oel-fips
The images support linux/amd64 and linux/arm64. Kratos and Hydra are built
with the Go Cryptographic Module v1.0.0, NIST CMVP certificate #5247. Polis uses
Red Hat's update stream of the Red Hat Enterprise Linux 9 OpenSSL FIPS Provider,
NIST CMVP certificate #4857. That certificate lists no arm64 operating
environment, and Red Hat supports the compliance claim only when the host kernel
runs in FIPS mode.
To deploy a FIPS image, set the image repository in the OEL Helm chart:
oss.image.repository in kratos-oel and hydra-oel, and image.repository
in polis-oel.
In FIPS mode, Kratos refuses to start unless secrets.default,
secrets.cookie, and secrets.pagination are set. Hydra refuses to start
unless secrets.system, secrets.cookie, and secrets.pagination are set,
each with its own first value. The charts do not map secrets.pagination, so
pass it through oss.deployment.extraEnv.
The Polis FIPS image derives datastore keys with SHA-256 instead of RIPEMD-160, so it cannot read a database that the standard image wrote. Choose the image when you create a deployment, and do not switch an existing one. The Polis FIPS image does not support Microsoft SQL Server.
Signatures and SBOM and CBOM attestations for OEL images
Ory now signs every OEL image and publishes each signature next to its image, on the enterprise registries and on Cloudsmith. All OEL images except the debug variants also carry two signed attestations: a Software Bill of Materials in SPDX format, and a CycloneDX document with the Software Bill of Materials and the Cryptography Bill of Materials.
This is now available for the Ory Enterprise License.
Ory Kratos
The Kratos FIPS build requires its secrets
The Kratos FIPS build now refuses to start unless secrets.default,
secrets.cookie, and secrets.pagination are set, like the Kratos OSS FIPS
build and Hydra. The migrate commands are exempt.
Breaking changes
Earlier Kratos FIPS builds started without these secrets. If you run the Kratos FIPS build, set all three secrets before you upgrade. The standard build is not affected.
FIPS 140-3 container images and Helm chart support for Kratos, Hydra, and Polis
Every Ory Enterprise License release now publishes FIPS 140-3 images of Ory Kratos, Ory Hydra, and Ory Polis next to the standard images, with the same tags:
europe-docker.pkg.dev/ory-artifacts/ory-enterprise-kratos/kratos-oel-fipseurope-docker.pkg.dev/ory-artifacts/ory-enterprise/hydra-oel-fips, also onus-docker.pkg.deveurope-docker.pkg.dev/ory-artifacts/ory-enterprise-polis/polis-oel-fips
The images support linux/amd64 and linux/arm64. Kratos and Hydra are built
with the Go Cryptographic Module v1.0.0, NIST CMVP certificate #5247. Polis uses
Red Hat's update stream of the Red Hat Enterprise Linux 9 OpenSSL FIPS Provider,
NIST CMVP certificate #4857. That certificate lists no arm64 operating
environment, and Red Hat supports the compliance claim only when the host kernel
runs in FIPS mode.
To deploy a FIPS image, set the image repository in the OEL Helm chart:
oss.image.repository in kratos-oel and hydra-oel, and image.repository
in polis-oel.
In FIPS mode, Kratos refuses to start unless secrets.default,
secrets.cookie, and secrets.pagination are set. Hydra refuses to start
unless secrets.system, secrets.cookie, and secrets.pagination are set,
each with its own first value. The charts do not map secrets.pagination, so
pass it through oss.deployment.extraEnv.
The Polis FIPS image derives datastore keys with SHA-256 instead of RIPEMD-160, so it cannot read a database that the standard image wrote. Choose the image when you create a deployment, and do not switch an existing one. The Polis FIPS image does not support Microsoft SQL Server.
Signatures and SBOM and CBOM attestations for OEL images
Ory now signs every OEL image and publishes each signature next to its image, on the enterprise registries and on Cloudsmith. All OEL images except the debug variants also carry two signed attestations: a Software Bill of Materials in SPDX format, and a CycloneDX document with the Software Bill of Materials and the Cryptography Bill of Materials.
This is now available for the Ory Enterprise License.
Ory Keto
Signatures and SBOM and CBOM attestations for OEL images
Ory now signs every OEL image and publishes each signature next to its image, on the enterprise registries and on Cloudsmith. All OEL images except the debug variants also carry two signed attestations: a Software Bill of Materials in SPDX format, and a CycloneDX document with the Software Bill of Materials and the Cryptography Bill of Materials.
This is now available for the Ory Enterprise License.
Ory Oathkeeper
Require positive token cache lifetimes for client credentials
The oauth2_client_credentials authenticator now rejects zero-duration
cache.ttl values. This fixes a security issue where a zero-duration TTL
allowed cached authentication results to remain usable beyond token expiry.
Tokens without an expiry are now cached for the configured positive TTL.
Breaking changes
If you configured a zero-duration TTL, remove cache.ttl to use the token
expiry, set a positive duration to limit the cache lifetime, or set
cache.enabled to false and remove cache.ttl to disable caching.
Signatures and SBOM and CBOM attestations for OEL images
Ory now signs every OEL image and publishes each signature next to its image, on the enterprise registries and on Cloudsmith. All OEL images except the debug variants also carry two signed attestations: a Software Bill of Materials in SPDX format, and a CycloneDX document with the Software Bill of Materials and the Cryptography Bill of Materials.
This is now available for the Ory Enterprise License and will be part of the next Ory Open Source release.
Ory Polis
Polis removes /api/hello and the setTenantAndProduct library method
Polis no longer serves the /api/hello route, the @boxyhq/saml-jackson
library no longer has setTenantAndProduct on its directory sync stores, and
Node.js 22.0 to 22.11 are no longer supported.
Breaking changes
/api/hello is removed
If you check that Polis started by requesting /api/hello, for example in a
load balancer or container health check, use /api/health instead. It responds
with the Polis version and edition, and with status 503 when Polis can't
connect to its database.
setTenantAndProduct is removed
The directory sync users, groups, and webhookLogs stores no longer have
setTenantAndProduct. It changed the shared store, so concurrent requests for
different tenants could read or write each other's data.
If you embed the library and call setTenantAndProduct, call
withTenantAndProduct instead. It takes the same arguments and returns a copy
of the store bound to that tenant and product:
const { data } = await directorySyncController.users
.withTenantAndProduct(tenant, product)
.getAll()Use the returned copy for every call. Calls on the shared store itself fail with "Set tenant and product before using store."
Node.js 22.0 to 22.11 are no longer supported
Polis and the @boxyhq/saml-jackson library now need Node.js 20.19.0 or later
in the 20 line, or 22.12.0 or later. Node.js 22.0 to 22.11 can't load the
openid-client and jose dependencies without the
--experimental-require-module flag. If you run one of those versions, upgrade
Node.js. The Polis container images already use Node.js 24.
FIPS 140-3 container images and Helm chart support for Kratos, Hydra, and Polis
Every Ory Enterprise License release now publishes FIPS 140-3 images of Ory Kratos, Ory Hydra, and Ory Polis next to the standard images, with the same tags:
europe-docker.pkg.dev/ory-artifacts/ory-enterprise-kratos/kratos-oel-fipseurope-docker.pkg.dev/ory-artifacts/ory-enterprise/hydra-oel-fips, also onus-docker.pkg.deveurope-docker.pkg.dev/ory-artifacts/ory-enterprise-polis/polis-oel-fips
The images support linux/amd64 and linux/arm64. Kratos and Hydra are built
with the Go Cryptographic Module v1.0.0, NIST CMVP certificate #5247. Polis uses
Red Hat's update stream of the Red Hat Enterprise Linux 9 OpenSSL FIPS Provider,
NIST CMVP certificate #4857. That certificate lists no arm64 operating
environment, and Red Hat supports the compliance claim only when the host kernel
runs in FIPS mode.
To deploy a FIPS image, set the image repository in the OEL Helm chart:
oss.image.repository in kratos-oel and hydra-oel, and image.repository
in polis-oel.
In FIPS mode, Kratos refuses to start unless secrets.default,
secrets.cookie, and secrets.pagination are set. Hydra refuses to start
unless secrets.system, secrets.cookie, and secrets.pagination are set,
each with its own first value. The charts do not map secrets.pagination, so
pass it through oss.deployment.extraEnv.
The Polis FIPS image derives datastore keys with SHA-256 instead of RIPEMD-160, so it cannot read a database that the standard image wrote. Choose the image when you create a deployment, and do not switch an existing one. The Polis FIPS image does not support Microsoft SQL Server.
Signatures and SBOM and CBOM attestations for OEL images
Ory now signs every OEL image and publishes each signature next to its image, on the enterprise registries and on Cloudsmith. All OEL images except the debug variants also carry two signed attestations: a Software Bill of Materials in SPDX format, and a CycloneDX document with the Software Bill of Materials and the Cryptography Bill of Materials.
This is now available for the Ory Enterprise License and will be part of the next Ory Open Source release.
Ory Network, Ory Elements, and Ory Terraform
No significant changes in this release.