Prometheus Adapter implements the custom.metrics.k8s.io and external.metrics.k8s.io APIs for Kubernetes HPA and VPA, exposing metrics from Prometheus.
Pull the latest version of this image from the Ghost registry. Pulling requires authentication — generate a token and run docker login first (see Authentication below).
The Ghost catalog is public to browse, but pulling images requires an account. Generate a pull token below (or from your Account → Tokens page) — you'll get a ready-to-paste docker login command, then docker pull works.
The username is generated automatically (it looks like robot$<project>+<auto-id>, not the name you typed) and is included in the docker login command above. The secret is shown only once when you create the token.
All Ghost images are signed with cosign. Verifying the signature before deployment ensures the image has not been tampered with.
Install cosign via brew install cosign or download from the Sigstore releases page.
Reference this image in your Dockerfile as a base layer:
All examples in this guide use the public image. If you've mirrored the repository for your own use (for example, to your Docker Hub namespace), update your commands to reference the mirrored image instead of the public one.
For example:
registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter:<tag><your-namespace>/dhi-prometheus-adapter:<tag>For the examples, you must first use docker login registry.ghost-prod.alphabravo.io to authenticate to the registry to pull the images.
This Ghost hardened image provides the Prometheus Adapter binary (/adapter) that implements the Kubernetes Custom and
External Metrics APIs using Prometheus as the backend. The adapter is intended to run inside a Kubernetes cluster where
it can use in-cluster configuration to access the API server and your Prometheus instance.
Prometheus Adapter is designed to run in a Kubernetes cluster as part of the custom metrics pipeline. Standalone
docker run is only useful for checking the binary (for example --help or ); the adapter will not serve
metrics without cluster and Prometheus access.
--versionThe recommended way to run Prometheus Adapter is via the prometheus-community/prometheus-adapter Helm chart, overriding the image to use the Ghost hardened image.
Prerequisites:
Install and use the DHI image:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus-adapter prometheus-community/prometheus-adapter \
--namespace monitoring \
--create-namespace \
--set image.registry=registry.ghost-prod.alphabravo.io \
--set image.repository=prometheus-adapter \
--set image.tag=<tag> \
--set image.pullSecrets[0].name=<your-registry-secret> \
--set prometheus.url=http://prometheus.monitoring.svc:9090
Replace <tag> with the desired image tag and <your-registry-secret> with your
Kubernetes image pull secret for registry.ghost-prod.alphabravo.io. Adjust prometheus.url to match
your Prometheus service.
Verify the deployment:
kubectl get deployment -n monitoring prometheus-adapter
kubectl get apiservice v1beta1.custom.metrics.k8s.io -o wide
If you use the Ghost hardened images Prometheus Adapter chart (which packages the same upstream chart with DHI
defaults), the image is already set to dhi/prometheus-adapter. Install with:
helm install my-prometheus-adapter registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter-chart:<version> \
-n monitoring --create-namespace
See the chart’s documentation for values and Prometheus URL configuration.
After the adapter is running and the Custom Metrics API is available, you can create an HPA that scales on a Prometheus
metric. The adapter must be configured with rules that map Prometheus metrics to the custom metrics API (see
upstream config documentation). For
example, an HPA that scales on http_requests_per_second:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 1
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: "1000"
| Feature | Non-hardened Prometheus Adapter | Docker Hardened Prometheus Adapter |
|---|---|---|
| Base image | Standard base with full utilities | Hardened Debian base |
| Security | Standard image, basic utilities | Hardened build, security patches, metadata |
| Shell access | Shell available | No shell (runtime variants) |
| Package manager | Package manager available | No package manager (runtime variants) |
| User | Often root or custom user | Runs as nonroot user |
| Attack surface | Full OS utilities | Only adapter binary and minimal deps |
| Debugging | Shell and standard tools | Use Docker Debug or image mount |
Ghost hardened images prioritize security through minimalism:
The hardened runtime image does not include a shell or debugging tools. To troubleshoot, use Docker Debug or an image mount to attach debugging tools.
Example with Docker Debug:
docker run -d --name adapter-test registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter:<tag>
docker debug adapter-test
# inside debug session: inspect files, env, etc.
docker rm -f adapter-test
Ghost hardened images come in different variants depending on their intended use. Image variants are identified by their tag.
Runtime variants are for running the adapter in production. They typically:
Use these when deploying with Helm or Kubernetes manifests.
To view the image variants and details, select the Tags tab for this repository and then select a tag.
To migrate from a non-hardened Prometheus Adapter image to a Ghost hardened image:
| Item | Migration note |
|---|---|
| Base image | Replace the adapter image in your Helm values or manifests with registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter:<tag>. |
| Non-root user | By default, the DHI image runs as a nonroot user. Ensure volumes and permissions (e.g. for TLS or config) are compatible; the upstream chart typically handles this. |
| Ports | The adapter’s secure port is typically 6443. Non-root images cannot bind to ports below 1024; the standard chart uses a high port. |
| Entrypoint | The image entrypoint is /adapter. If your manifests override the command, keep args compatible with the upstream adapter (e.g. --cert-dir, --prometheus-url, --config). |
| No shell | Runtime images do not include a shell. Use Docker Debug for ad-hoc debugging; use Helm/Kubernetes tooling for logs and exec where a shell is expected. |
Steps:
Choose a tag Pick the DHI image tag (e.g. 0.12.0-debian13-0) from the Tags tab.
Update Helm or manifests Set image.registry, image.repository, and image.tag (and digest if desired) to the
DHI image. Add image.pullSecrets if required for registry.ghost-prod.alphabravo.io.
Point to Prometheus Configure prometheus.url (or equivalent) so the adapter can reach your Prometheus server.
Configure metric rules Keep or adjust the adapter’s rules (ConfigMap or chart values) so the correct Prometheus metrics are exposed to the Custom/External Metrics APIs.
Runtime images do not include a shell. Use Docker Debug to attach to a container and inspect files, environment, and processes.
The image runs as a nonroot user. If the adapter fails to read config or certificates, check volume mounts and file ownership in your Helm values or Pod spec.
If kubectl get apiservice v1beta1.custom.metrics.k8s.io shows as not available, check:
kubectl logs -n monitoring deployment/prometheus-adapter -c prometheus-adapter.To see the image entrypoint and default command:
docker inspect registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter:<tag> --format '{{json .Config.Entrypoint}}'
For supported flags, run:
docker run --rm registry.ghost-prod.alphabravo.io/ghost-base/prometheus-adapter:<tag> --help