Containers & Orchestration

Docker, Kubernetes, and orchestration endpoints that can expose clusters and secrets.

22 probed paths in this category.

api/v1/containerd/containers

containerd Container Management

Risk: An exposed containerd API lets an attacker list, create, and exec into containers on the host, pulling arbitrary images and mounting host paths to break out to the underlying node.

Fix: Bind the containerd gRPC socket to a local Unix socket only, restrict its file permissions to root, and never expose the CRI endpoint over TCP or an ingress.

api/v1/istio/config

Istio Service Mesh Configuration

Risk: Exposed Istio configuration reveals mesh topology, routing rules, and mTLS/authorization policies, letting an attacker map internal services and craft requests that bypass intended traffic and security policies.

Fix: Keep the Istio control plane (istiod) and its config APIs internal to the cluster, enforce RBAC on Istio CRDs, and require STRICT mutual TLS for mesh traffic.

api/v1/kubernetes/pods

Kubernetes Pods API

Risk: Unauthenticated access to the pods API reveals running workloads, images, environment variables, and node assignments, and write access allows scheduling malicious pods with hostPath mounts to compromise nodes.

Fix: Require authentication and enforce RBAC on the Kubernetes API server, disable anonymous-auth, and never expose the API server or kubelet read endpoints to the public internet.

api/v1/kubernetes/secrets

Kubernetes Secrets API

Risk: Reading the secrets API exposes base64-encoded credentials, TLS private keys, service-account tokens, and database passwords, giving an attacker the keys to pivot across the entire cluster and connected services.

Fix: Lock down secrets with least-privilege RBAC, enable encryption-at-rest for etcd, and use an external secret store (e.g. Vault or a CSI driver) instead of plaintext Kubernetes Secrets.

argocd/api/v1/applications

ArgoCD Applications API

Risk: Access to the ArgoCD applications API exposes Git repo URLs, cluster targets, and sync state, and with write access an attacker can point an app at a malicious manifest source to deploy arbitrary workloads cluster-wide.

Fix: Disable the anonymous account, enforce SSO and project-scoped RBAC, and keep the ArgoCD API server off the public internet behind a VPN or authenticated ingress.

configmap.yaml

Kubernetes ConfigMap

Risk: A ConfigMap reveals internal service names, environment variables, feature flags, and backend endpoints that help an attacker map the cluster and locate higher-value targets.

Fix: Do not expose Kubernetes manifests via HTTP, store them in access-controlled repos, and keep sensitive values in Secrets rather than ConfigMaps.

consul/v1/agent/self

HashiCorp Consul Agent Info

Risk: The agent-self endpoint discloses Consul version, datacenter, node name, and configuration, and an open HTTP API lets an attacker read service registrations, KV secrets, and register malicious services.

Fix: Enable ACLs with a default-deny policy and TLS, bind the HTTP API to localhost or a private network, and require tokens for all API access.

docker-compose.yml

Docker Compose Configuration

Risk: Reveals service topology, container image versions, mounted volume paths, and frequently hard-coded database passwords, API keys, and environment variables an attacker can use to pivot into backing services.

Fix: Keep compose files out of the web root and never commit them to a public repo; load secrets from a secrets manager or .env file referenced via env_file rather than inline literals.

Dockerfile

Docker Image Configuration

Risk: Discloses base image and version (enabling targeted CVE exploitation), build steps, exposed ports, and any ARG/ENV secrets or embedded credentials baked into the image.

Fix: Exclude Dockerfiles from the public document root and use multi-stage builds with build secrets so credentials never persist; serve nothing matching the build artifact paths.

envoy/admin/clusters

Envoy Proxy Admin Interface

Risk: The Envoy admin interface discloses upstream cluster endpoints and health, and exposes endpoints to drain listeners, change log levels, or dump configs and the heap, enabling reconnaissance and denial of service.

Fix: Bind the Envoy admin listener to 127.0.0.1 only, never expose it via a route or ingress, and restrict it with network policies.

etcd/v2/stats/leader

etcd Leader Statistics

Risk: Leader stats disclose cluster membership and the etcd version, and an unauthenticated etcd holds Kubernetes and application secrets that an attacker can read or overwrite to seize the cluster.

Fix: Enable client and peer TLS with certificate authentication, bind etcd to private interfaces only, and never expose it directly to untrusted networks.

flux/api/v1/helmreleases

Flux Helm Releases API

Risk: Exposed Flux HelmRelease resources reveal source repositories and chart values (potentially including credentials), and tampering with reconciled definitions lets an attacker deploy compromised charts via GitOps automation.

Fix: Restrict access with Kubernetes RBAC, store HelmRelease values referencing secrets rather than inline credentials, and verify sources with signed commits and OCI signature checks.

harbor/api/v2.0/projects

Harbor Container Registry API

Risk: An open Harbor API enumerates registry projects, repositories, and image tags, and weak or default admin credentials let an attacker pull private images or push backdoored ones consumed by deployments.

Fix: Change the default admin password, enforce authentication and project-level RBAC, enable content trust/cosign signing, and front the registry with TLS-only access controls.

helm/api/charts

Helm Chart Repository API

Risk: An exposed ChartMuseum-style repository lets an attacker enumerate deployed application versions for vulnerability targeting and, if writable, upload trojaned charts that get installed into the cluster.

Fix: Place the chart repository behind authentication, make it read-only for anonymous users or fully private, and verify chart provenance with signed (cosign/GPG) charts.

kubernetes.yaml

Kubernetes Configuration

Risk: Exposes cluster manifests including namespaces, service accounts, image references, and any inline Secrets or ConfigMap data, giving an attacker a map of the deployment and potential base64-encoded credentials.

Fix: Store manifests in version control behind access controls, never in the web root; keep Secret material in a sealed-secrets or external secrets store rather than plaintext YAML.

linkerd/api/v1/version

Linkerd Service Mesh API

Risk: The Linkerd version endpoint fingerprints the exact service-mesh build, letting an attacker match it against known CVEs, and a broadly reachable control plane API risks deeper mesh reconnaissance.

Fix: Keep the Linkerd control plane namespace internal to the cluster, gate its dashboard and APIs behind authentication, and patch to a supported release promptly.

minio/health/live

MinIO Storage Health Check

Risk: A reachable MinIO health check confirms an object store is present and exposes its version, which scanners pair with default or weak credentials to list and exfiltrate stored buckets.

Fix: Rotate away from default access keys, enforce strong credentials and bucket policies, restrict the console and API to private networks, and keep MinIO updated.

nomad/v1/agent/self

HashiCorp Nomad Agent Info

Risk: The agent-self endpoint exposes Nomad version, region, and config, and an unauthenticated API allows job submission that runs attacker-controlled workloads and reaches host resources.

Fix: Enable Nomad ACLs and mTLS, bind the HTTP API to private networks, and require tokens before any job submission or agent introspection.

podman/libpod/info

Podman System Information

Risk: The Podman libpod info endpoint discloses host OS, kernel, cgroup, and runtime details, and if the wider API socket is reachable an attacker can create privileged containers to escape to the host.

Fix: Run the Podman API service rootless on a Unix socket with strict permissions, and never bind the libpod REST API to a network interface.

registry/v2/_catalog

Container Registry Catalog

Risk: The Docker Registry v2 catalog lists every repository name on the registry, enabling an attacker to enumerate and pull all stored images, and on an unauthenticated registry to push malicious replacements.

Fix: Require token authentication on the registry, disable or restrict the _catalog endpoint, and serve only over TLS behind an authenticating proxy.

v2/_catalog

Docker registry

Risk: An unauthenticated Docker Registry v2 catalog endpoint lists every repository, letting an attacker pull private images to extract embedded secrets, source code, and credentials, or push malicious images if writes are also open.

Fix: Require authentication and TLS on the registry, place it behind an authenticating proxy or token service, and never bind it to a public interface without access controls.

vault/v1/sys/health

HashiCorp Vault Health Status

Risk: The health endpoint reveals Vault version, seal status, and HA state, helping an attacker time attacks against an unsealed instance and fingerprint version-specific vulnerabilities.

Fix: Restrict network access to Vault to trusted clients, enforce TLS and audit logging, keep Vault patched, and ensure auth methods and policies follow least privilege.

← All categories