Replace the manual library exclusion list with automated dependency
resolution using apt-cache. The approach queries the dependency tree
of packages in the distroless base image (from GoogleContainerTools
distroless configs) and excludes them from our requirements.
This reduces the image to 260MB (down from 270MB) by avoiding
duplicate libraries already present in the distroless base. Only 7
packages are now downloaded instead of manually maintaining a list
of 13 exclusions.
The package list is sourced from distroless upstream configs and
documented with URLs, making it maintainable as distroless evolves.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Switch from python:3.13-slim-trixie to distroless/python3-debian13
for the sidecar container. The virtualenv approach now extracts
runtime libraries from Debian packages using dpkg, eliminating the
need for apt and package management tools in the final image.
The image is 44% smaller (260MB vs 463MB on main, or 31% vs 377MB
from the previous commit) with 70% fewer packages (35 vs 115) while
maintaining zero HIGH/CRITICAL vulnerabilities. There is no shell
or package manager in the final image, reducing the attack surface
significantly.
Based on Google's distroless best practices.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Barman-cloud requires lz4 and snappy compression libraries for
backup and WAL compression. The pythonbuilder stage needs the
development headers (liblz4-dev, libsnappy-dev) to compile the
Python C-extensions into wheels, and the final runtime image
needs the shared libraries (liblz4-1, libsnappy1v5) for the
extensions to function.
Without these dependencies, backups fail when attempting to
compress data, causing the backup to enter a failed state.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The sidecar uses a read-only filesystem which prevents Python from
creating bytecode at runtime. The previous approach pre-compiled
bytecode in a separate base image, but timestamps were corrupted
when files were copied between Docker stages, causing Python to
mark the bytecode as stale and recompile on every invocation.
This change builds Python dependencies as wheels in a pythonbuilder
stage using BuildKit cache mounts, then installs them in the final
python:3.13-slim-trixie stage using a bind mount. Wheels include
pre-compiled bytecode with correct timestamps. The bind mount keeps
wheels out of final layers, and the distroless complexity is
eliminated.
After wheel installation, we run compileall to ensure all Python
bytecode is freshly compiled with correct timestamps, preventing
any stale bytecode from remaining in the final image.
The separate barmanbase image, its workflow, and related Renovate
configuration are no longer needed and have been removed.
Closes#711Closes#735
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Pin all e2e test emulator images to specific SHA256 digests to ensure
immutability and prevent unexpected breakage from upstream changes.
The three emulators (Azurite for Azure, MinIO for S3, and
fake-gcs-server for GCS) were previously using the :latest tag, which
could cause test failures when new versions with breaking changes or
bugs were released.
Using SHA256 digests instead of version tags provides immutability
(ensures we always pull the exact same image), transparency (easy to
verify what's running via digest comparison), and Renovate compatibility
(can still track and propose updates). All pinned SHAs match the current
:latest tag, confirming we're using the same images that were previously
tested.
Updated Renovate configuration to track digest-based updates while
preserving version information in comments for human readability. Fixed
Renovate to scan test directories and handle multi-line regex patterns
for .go files.
Also fixed Azurite compatibility issue by adding the
--skipApiVersionCheck flag. Tests were failing because the PostgreSQL
container images install Python dependencies without version pinning,
which resulted in azure-storage-blob 12.28.0 (released January 6, 2026)
being installed. This version uses API version 2026-02-06 which Azurite
3.35.0 doesn't support yet. The flag allows Azurite to accept any API
version in the test environment.
Note that MinIO is now in maintenance mode and will not receive further
updates, but it has been included for completeness.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Pin crd-ref-docs to v0.2.0 (latest stable release) instead of using the
master branch. This prevents issues from upstream changes and provides
better control over when to adopt new versions.
Configure Renovate to automatically track and update the version,
allowing us to review and test changes before merging.
Closes#722
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This PR adds a disclaimer to the object stores documentation clarifying
that the Barman Cloud Plugin does not independently test all
authentication methods supported by barman-cloud. The plugin's
responsibility is limited to passing the provided credentials to
barman-cloud, which then handles authentication according to its own
implementation.
This documentation change was decided by the maintainers as part of the
discussion around Azure Default Credentials support (#662).
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This commit adds support for the DefaultAzureCredential authentication
mechanism in Azure Blob Storage. Users can now use the
`useDefaultAzureCredentials` option to enable Azure's default credential
chain, which automatically discovers and uses available credentials in
the following order
1. Environment Variables (Service Principal)
2. Managed Identity
3. Azure CLI
4. Azure PowerShell
This is particularly useful when running on Azure Kubernetes Service
(AKS) with Workload Identity, eliminating the need to explicitly store
credentials in Kubernetes Secrets.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This change fixes Azure credentials validation to require a storage
account when using explicit credentials such as a storage key or SAS
token, and ensures the connection string is mutually exclusive with
other authentication parameters.
Closes#705
Related: cloudnative-pg/barman-cloud#177
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Follow-up to #700 to align the targetTime documentation with
cloudnative-pg standards. The note now covers all timestamp formats (not
just RFC 3339) and uses PostgreSQL format in the example to avoid
advertising the non-standard RFC3339-like format without timezone. A
warning has been added recommending to always specify an explicit
timezone to avoid ambiguity.
Related: #699
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Update the machinery dependency to include the fix that ensures
RFC3339-like timestamps without timezone (e.g., "2024-01-15T10:30:00")
are interpreted as UTC.
The documentation has been updated to use a targetTime example with an
explicit Z suffix and to clarify that RFC3339-like timestamps without timezone
are interpreted as UTC.
Closes#699
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
