Supported base image / custom runtime image for Hasura GraphQL Engine v2.45.5

[minoosr1]

We currently run:

FROM hasura/graphql-engine:v2.45.5

Due to our container security policy, the final runtime image must use a Wiz Secured Image Catalog base image.

We would like to continue using Hasura GraphQL Engine v2.45.5 and avoid migrating to v3.

Our available secured base is:

registry.os.wiz.io/wizos-base:latest

It is a minimal Linux image with glibc and apk.

We are considering a multi-stage image like:

FROM hasura/graphql-engine:v2.45.5 AS hasura

FROM registry.os.wiz.io/wizos-base:latest

COPY --from=hasura /bin/graphql-engine /usr/local/bin/graphql-engine

We would appreciate guidance on the following:

What base OS/image is hasura/graphql-engine:v2.45.5 built on?
Is /bin/graphql-engine intended to be portable to another glibc-based Linux runtime, or are there additional runtime files that must be copied?
What are the complete runtime shared-library dependencies required by the v2.45.5 graphql-engine binary?
Are there any required files/directories besides the binary, such as:
/srv/console-assets
CA certificates
locale/timezone data
PostgreSQL client libraries
OpenSSL libraries
ICU or other native libraries
Is there a supported Dockerfile or build target for producing a minimal/runtime-only v2 image from source?
If we need to build v2.45.5 ourselves, what is the recommended build process and toolchain for that exact tag?
Is copying the graphql-engine binary from the official image into our secured runtime image considered a supported deployment approach?
Are there any assumptions made by the v2 server about the underlying distro beyond having compatible glibc and shared libraries?

Our goal is to keep the Hasura version and behavior unchanged while replacing only the final container base for security/compliance reasons.

[jmrplens]

You may not need to build anything: Hasura already publishes hasura/graphql-engine:v2.45.5.ubi, your exact version on a Red Hat UBI 9 minimal base, with no Ubuntu and no Perl. I checked the rest of your list against the real images anyway, because a couple of the answers are not what the usual tools report.

What the official v2.45.5 image is

hasura/graphql-engine:v2.45.5 is Ubuntu 22.04.5 LTS (Jammy), 336 MB, CMD ["/bin/sh","-c","${HGE_BINARY} serve"] with HGE_BINARY=graphql-engine and LANG=LC_ALL=C.UTF-8, no USER set. The build files are in the repo at that tag: packaging/graphql-engine-base/ubuntu.dockerfile and, next to it, ubi.dockerfile. That second file is the answer to your "is there a supported build target" question, and it is what produces the .ubi tags.

The Perl your scanner is flagging is not incidental: /usr/bin/pg_dump is a symlink to /usr/share/postgresql-common/pg_wrapper, and that wrapper starts with #!/usr/bin/perl. Perl is in the image to run pg_dump. That is the same finding as #10857, which was closed with a 2.49 release; on the 2.45 Ubuntu image perl 5.34.0 is still present, and I confirmed the .ubi image has no perl binary at all.

Is the binary portable, and what does it link against

This is the part where the usual tools mislead you. /bin/graphql-engine (hardlinked to /usr/bin/graphql-engine, 24 MB) is a statically linked ELF: three program headers, no INTERP, no DT_NEEDED. ldd reports not a dynamic executable and readelf -d reports nothing, so static analysis suggests it needs nothing at all.

It does. It dlopens its dependencies at runtime, so the only way to enumerate them is to run it and read the failures. I built exactly your multi-stage against a public minimal glibc+apk base (Chainguard's wolfi-base, the same shape as the Wiz one) and added libraries until it started. It needs 23:

libpcre.so.3      libodbc.so.2       libstdc++.so.6     libpq.so.5
libgmp.so.10      libltdl.so.7       libgssapi_krb5.so.2 libldap-2.5.so.0
libkrb5.so.3      libk5crypto.so.3   libcom_err.so.2    libkrb5support.so.0
liblber-2.5.so.0  libsasl2.so.2      libgnutls.so.30    libkeyutils.so.1
libp11-kit.so.0   libidn2.so.0       libunistring.so.2  libtasn1.so.6
libnettle.so.8    libhogweed.so.6    libffi.so.8

Most of that tail is the transitive closure of libpq (Kerberos, LDAP, SASL, GnuTLS). One gotcha if you copy them: Ubuntu keeps them under /lib/x86_64-linux-gnu/, which a non-Debian base does not search, so they have to land somewhere on the loader path such as /usr/lib/.

With those 23 libraries and nothing else, the server does work. GET /healthz returns 200, /v1/version reports {"server_type":"ce","version":"v2.45.5"}, a real /v1/graphql introspection query answers, it connects to Postgres by hostname, and adding a remote schema over HTTPS succeeds. Final image, 52 MB.

What copying only the binary loses

pg_dump. The pgdump API is in enabled_apis by default (visible in the startup log), and without the binary the endpoint fails:

POST /v1alpha1/pg_dump
{"error":"internal exception while executing pg_dump","code":"unexpected",
 "internal":"pg_dump: readCreateProcessWithExitCode: posix_spawnp: does not exist (No such file or directory)"}

That is the same class of breakage as #10854, where a UBI image shipped a pg_dump whose libpq did not match and hasura seed create died with undefined symbol: PQmblenBounded. Whatever base you land on, pg_dump and its libpq have to agree. The .ubi image installs pg_dump 17.9 from the PGDG RPM directly, which is how it avoids both the Perl wrapper and that mismatch.

Console assets. /srv/console-assets is 31 MB and is not in a binary-only image. It only matters if you cannot reach the CDN: with console_assets_dir unset the console loads from https://graphql-engine-cdn.hasura.io/console/assets. If your policy blocks that egress, copy the directory and set --console-assets-dir / HASURA_GRAPHQL_CONSOLE_ASSETS_DIR, which the server's own --help describes as "Can be set to '/srv/console-assets' on the default docker image to disable loading assets from CDN".

Smaller things. The CMD shells out, so the base needs /bin/sh or you override CMD with an exec form. Keep LANG/LC_ALL=C.UTF-8. A CA bundle at /etc/ssl/certs/ca-certificates.crt is required for outbound TLS; my base already shipped one, so check yours rather than assuming. There is no tzdata in the official image either, so that is not something you would be dropping.

What I would actually do

Use hasura/graphql-engine:v2.45.5.ubi. It is the same engine version, RHEL 9.6 UBI minimal, 234 MB against 336 MB, no Perl, pg_dump present and matched. If your policy requires the Wiz base specifically rather than any hardened base, then the ubi.dockerfile in the repo is the template to adapt, and it is a much safer starting point than a binary copy because it already solves the pg_dump, locale and user parts.

One last thing, since your driver is a vulnerability scan rather than a feature: v2.45.5 is not the end of the 2.45 line. v2.45.6 and v2.45.8 are published, .ubi variants exist for all of them, and none of that is a v3 migration.