This part does not assume CSG Quote & Order uses a specific base image,
a specific Dockerfile style, a specific image registry, distroless images,
Buildpacks, Jib, Docker multi-stage builds, or a specific runtime user model.

Treat Dockerfile structure, base image, registry, scanning tools, artifact signing,
and runtime hardening policy as internal verification items.

large attack surface
slow cold start
inconsistent timezone/locale behavior
wrong CA certificates
permission failure at runtime
heap/native memory mismatch
hidden writable filesystem dependency
unnecessary shell/debug tool exposure
hard-to-patch OS vulnerabilities
untraceable deployment artifact

Can this image be built reproducibly?
Can it run safely as non-root?
Can it be patched quickly?
Can it expose only what the service needs?
Can it fail predictably?
Can operators debug it without weakening production security?

read-only filesystem layers
metadata
entrypoint/command
environment defaults
working directory
user/group
exposed port declaration
labels

writable container layer
network namespace
process namespace
cgroup limits
mounted volumes/secrets/config
runtime environment variables
security context

A container image should contain what the process needs to start and run.
Runtime configuration should generally be injected by platform, not baked into image.

JRE/JDK runtime or custom runtime
application artifact
startup script or direct java command
trusted CA certificates
minimal OS files required by JVM/native libraries
optional diagnostics hooks
metadata labels

production secrets
environment-specific config
developer credentials
local test data
source code unless required by runtime
build tool caches
unused package managers
SSH keys
large debug tools by default

COPY application-prod.properties /app/application.properties
COPY ~/.aws /root/.aws
COPY target/ /app/

The image becomes environment-specific, hard to promote, and risky to share.

same image promoted across environments
runtime config injected by environment
image digest identifies executable code
config identity tracked separately

Does the app start with java -jar?
Does it deploy as WAR into a servlet container?
Is Jersey embedded in the service?
Is there an external app server image?
Does the image contain Tomcat/Jetty/GlassFish/Grizzly?

@Path("/quotes")
public class QuoteResource {
    @GET
    public Response listQuotes() { ... }
}

Tomcat + Jersey servlet
Jetty + Jersey servlet
GlassFish
embedded Grizzly
custom platform launcher

FROM eclipse-temurin:17-jre

WORKDIR /app

COPY target/quote-service.jar /app/quote-service.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/app/quote-service.jar"]

Which base image variant?
Is it patched?
Is it root?
Are JVM options configurable?
Is timezone/locale expected?
Are CA certs present?
Is the artifact verified?
Are labels added?
Is the image scanned?

FROM eclipse-temurin:17-jre

LABEL org.opencontainers.image.title="quote-service"
LABEL org.opencontainers.image.description="JAX-RS quote service"
LABEL org.opencontainers.image.source="internal-repo-placeholder"
LABEL org.opencontainers.image.revision="build-arg-placeholder"

RUN groupadd --system app && useradd --system --gid app --home-dir /app app

WORKDIR /app
COPY --chown=app:app target/quote-service.jar /app/quote-service.jar

USER app

EXPOSE 8080

ENV JAVA_OPTS=""
ENTRYPOINT ["sh", "-c", "exec java $JAVA_OPTS -jar /app/quote-service.jar"]

ENTRYPOINT ["java", "-jar", "/app/quote-service.jar"]

JAVA_TOOL_OPTIONS
JDK_JAVA_OPTIONS

FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /src
COPY pom.xml .
COPY src ./src
RUN mvn -B -DskipTests package

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=build /src/target/quote-service.jar /app/quote-service.jar
USER 10001
ENTRYPOINT ["java", "-jar", "/app/quote-service.jar"]

build tools do not exist in final image
runtime image is smaller
attack surface is reduced
artifact is produced in controlled build stage

Docker build may bypass CI Maven cache/governance
build may behave differently from CI command
dependency download inside Docker may be slow/non-reproducible
secret access during build may leak into layers

Some organizations build artifact in CI first, then copy it into image.
Others use Docker multi-stage as the build itself.
Either can work, but the source of truth must be explicit.

COPY target/app.jar /app/app.jar

/app/libs/*.jar
/app/classes
/app/resources

better cache reuse
faster rebuilds
clearer dependency/application separation
smaller incremental transfer

more complex build
classpath correctness risk
framework-specific packaging assumptions
harder local reproduction if generated incorrectly

COPY target/dependency /app/libs
COPY target/classes /app/classes

ENTRYPOINT ["java", "-cp", "/app/classes:/app/libs/*", "com.example.Main"]

Is the image optimized for build speed, runtime simplicity, or both?

JVM distribution
OS package surface
glibc vs musl compatibility
CA certificates
timezone database
security patch cadence
debug capability
image size
scanner findings

Who owns patching this base image?
How quickly can critical CVEs be fixed?
Is the base image approved internally?
Does it include required CA certs and timezone data?
Does it support the JVM distribution expected by performance tests?

FROM latest

FROM eclipse-temurin:17.0.XX_YY-jre

FROM internal-registry/java17-runtime@sha256:...

production diagnostics require jcmd/jstack/jmap
heap/thread dump tools are expected inside container
attach mechanism is enabled
support team relies on JVM tools in image

attack surface must be reduced
image size matters
runtime is simple
external diagnostics sidecars/tools exist

module detection
missing module risk
security update process
less common operational knowledge

Prefer the smallest runtime that still supports required operations, diagnostics,
security patching, and platform standards.

filesystem write escalation inside container
weaker defense-in-depth
larger blast radius for container escape paths
policy violation in restricted clusters

RUN groupadd --system app \
 && useradd --system --gid app --home-dir /app app

WORKDIR /app
COPY --chown=app:app target/app.jar /app/app.jar
USER app

USER 10001:10001

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false

Does the image run as non-root?
Does the app need write permission anywhere?
Are writable directories explicit?
Does Kubernetes securityContext align with image USER?

temporary upload files
JVM temporary directory
heap dump directory
log file directory if not logging to stdout
application-generated cache

RUN mkdir -p /app/tmp /app/dumps \
 && chown -R 10001:10001 /app/tmp /app/dumps

ENV JAVA_TOOL_OPTIONS="-Djava.io.tmpdir=/app/tmp"

volumes:
  - name: tmp
    emptyDir: {}

volumeMounts:
  - name: tmp
    mountPath: /app/tmp

application writes into current working directory without policy
application writes logs to files only
application assumes /tmp is unlimited
heap dumps written into container layer until disk exhaustion

application writes structured logs to stdout/stderr
container runtime captures logs
platform ships logs to central backend

/app/logs/*.log only
rotating file appender only
logs inside ephemeral container filesystem

Some legacy app servers or compliance systems may require file logs.
If so, mount volumes and define retention/rotation explicitly.

request logs
error logs
audit logs
security logs
access logs

EXPOSE 8080

ports:
  - containerPort: 8080

liveness  = should Kubernetes restart me?
readiness = should traffic be sent to me?
startup   = do I need more time before liveness applies?

large image pull time
slow classpath scan
slow app server boot
schema migration at startup
remote config fetch
JIT warmup
cache preloading

ENTRYPOINT java -jar /app/app.jar

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

ENTRYPOINT ["sh", "-c", "exec java $JAVA_OPTS -jar /app/app.jar"]

Kubernetes sends SIGTERM
shell does not forward properly
JVM does not shutdown gracefully
in-flight requests are killed
Kafka consumer does not commit/close cleanly
connection pool does not close

Does ENTRYPOINT use exec form or exec inside shell?
Does app handle SIGTERM?
Does platform terminationGracePeriodSeconds match shutdown time?

JAVA_TOOL_OPTIONS
JDK_JAVA_OPTIONS
container env var expanded by shell entrypoint
config map / deployment manifest
platform standard wrapper

env:
  - name: JAVA_TOOL_OPTIONS
    value: >-
      -XX:MaxRAMPercentage=75
      -XX:+ExitOnOutOfMemoryError
      -Djava.security.egd=file:/dev/urandom

Where are JVM flags defined?
Are flags environment-specific?
Are they visible in deployment manifests?
Are they audited during incident review?
Are they consistent with memory limits?

PKIX path building failed
certificate_unknown
unable to find valid certification path
works locally, fails in pod
works in one environment, fails in another

OS CA bundle
JVM cacerts
custom truststore
service mesh injected certificates
enterprise root CA

Does the base image contain CA certificates?
Does Java trust the same CA set as OS tools?
Are enterprise CAs injected at build time or runtime?
Is truststore update process documented?

trustAllCertificates();
disableHostnameVerification();

log timestamp rendering
default JVM timezone
date parsing fallback
legacy library behavior
report generation
string collation behavior

ENV TZ=UTC
ENV JAVA_TOOL_OPTIONS="-Duser.timezone=UTC"

Is service expected to run in UTC?
Does code use explicit ZoneId/Clock?
Does container include timezone database if local zones are used?
Are logs normalized?

they can be visible in process metadata
they can leak through diagnostics
they are often copied into crash reports
many frameworks log environment at startup

mounted secret file
external secret operator
cloud secret manager SDK
service mesh identity
workload identity

redact them in logs
avoid dumping full environment
separate secret and non-secret config
validate required config at startup

source repository
commit SHA
build timestamp
version
vendor/team
license/SBOM pointer
base image identity

ARG VCS_REF
ARG BUILD_DATE
ARG VERSION

LABEL org.opencontainers.image.revision="$VCS_REF"
LABEL org.opencontainers.image.created="$BUILD_DATE"
LABEL org.opencontainers.image.version="$VERSION"

Which commit is running?
Which base image was used?
Which dependency set exists?
Which vulnerability scan applied?
Which environment received this digest?

image: registry.example.com/quote-service@sha256:...

OS packages
language dependencies if scanner supports them
base image layers
installed tools

severity policy
false positive workflow
base image patch process
dependency update ownership
exception expiry
release gate
SBOM linkage

A critical CVE exists in base image.
Application team cannot patch because base image is owned elsewhere.
Release is blocked without clear exception process.

Can this team patch a critical vulnerability in less than the required SLA?

smaller image
fewer packages
less interactive attack surface
fewer scanner findings
stronger production posture

harder exec-based debugging
no shell for emergency inspection
certificate/timezone customization may be different
startup scripts may not work
operators need alternative diagnostics

Use minimal/distroless only when diagnostics, patching, truststore management,
and platform support are mature enough.

Does the company standard allow distroless?
Do runbooks assume shell access?
Are debug containers allowed?
Does platform support ephemeral containers?

FROM tomcat:10-jre17
COPY target/quote-service.war /usr/local/tomcat/webapps/ROOT.war

server version
servlet/Jakarta namespace compatibility
default apps removed?
management endpoints disabled?
server.xml hardened?
thread pool configured?
access logs controlled?
TLS terminated elsewhere?

application code
app server code/config

Jersey + Grizzly embedded
Jersey + embedded servlet container
custom main class
framework launcher

who configures thread pool?
who owns graceful shutdown?
how are providers registered?
how is HTTP port configured?
how are access logs emitted?
how are TLS/proxy headers handled?

ARG PRIVATE_REPO_TOKEN
RUN curl -H "Authorization: Bearer $PRIVATE_REPO_TOKEN" ...

image layers
build logs
cache metadata
intermediate stages
CI environment snapshots

Build uses authenticated CI dependency access.
Final image contains only runtime artifact.
No secret value is copied into image.

.git
.idea
.vscode
*.iml
target/
node_modules/
*.log
.env
*.pem
*.key

COPY . /app

Is .dockerignore present?
Does build context include secrets?
Does Dockerfile copy explicit files only?
Does CI scan final image for unexpected files?

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080

Where is the source of truth for health checks: Dockerfile, Helm chart,
Kubernetes manifest, platform template, or app server config?

service cannot safely receive traffic
critical dependency/config missing
schema incompatible
startup initialization incomplete

include minimal JVM diagnostic tools
use sidecar/ephemeral debug container
enable remote diagnostic endpoints carefully
capture thread dumps via signal/actuator/admin API
use platform log/metrics/tracing

SSH daemon inside container
permanent debug port open in production
shell + package manager solely for convenience
verbose secrets in startup logs

A production image must be debuggable through approved operational paths,
not through ad-hoc insecure access.

pull time
node cache pressure
rollout speed
registry storage
CVE surface

CA certificates
timezone database
fonts required by reports
native libraries
JVM diagnostic tools

1. Remove build tools from final image
2. Use appropriate runtime base
3. Avoid copying unnecessary files
4. Layer dependencies properly if useful
5. Consider minimal/distroless when operations can support it

1. Inspect image metadata
2. Inspect container logs
3. Inspect Kubernetes events
4. Check exit code
5. Check entrypoint/command
6. Check mounted config/secrets
7. Check security context
8. Check filesystem permissions
9. Check probes
10. Check JVM flags and memory limits

docker image inspect <image>
docker run --rm <image>
docker run --rm --entrypoint sh <image>
kubectl describe pod <pod>
kubectl logs <pod>
kubectl get events

[ ] Is the base image approved and patched?
[ ] Is the runtime Java version correct?
[ ] Is the image environment-independent?
[ ] Are secrets excluded from image layers?
[ ] Is .dockerignore present and strict?
[ ] Does the image run as non-root?
[ ] Are writable directories explicit?
[ ] Is ENTRYPOINT signal-safe?
[ ] Are JVM options injected through platform standard?
[ ] Are CA certificates/truststore requirements handled?
[ ] Are timezone/locale assumptions explicit?
[ ] Are logs written to stdout/stderr or approved sink?
[ ] Is the image labeled for traceability?
[ ] Is image scanning integrated?
[ ] Is artifact signing/provenance handled?
[ ] Does image packaging match runtime architecture: JAR, WAR, app server?
[ ] Are health/probe expectations aligned with deployment manifests?
[ ] Is debugging possible through approved operational tooling?

[ ] Is packaging JAR, WAR, exploded app, or platform-specific artifact?
[ ] Which base image is used?
[ ] Is the base image centrally owned?
[ ] Is the runtime Java version Java 17+?
[ ] Is the runtime JDK, JRE, custom jlink runtime, or app server image?
[ ] Does the image include Tomcat, Jetty, GlassFish, Grizzly, or custom launcher?
[ ] Does the container run as root or non-root?
[ ] What UID/GID does Kubernetes expect?
[ ] Where are JVM flags defined?
[ ] Are `JAVA_TOOL_OPTIONS` or `JDK_JAVA_OPTIONS` used?
[ ] Is the image environment-independent?
[ ] Are production secrets ever copied into image layers?
[ ] Is `.dockerignore` present?
[ ] Are CA certificates or enterprise truststores required?
[ ] How is timezone configured?
[ ] Where do logs go?
[ ] Are audit/security logs handled differently from application logs?
[ ] Are image labels added for commit/build/version?
[ ] Are images deployed by tag or digest?
[ ] What scanner checks image vulnerabilities?
[ ] Is SBOM generated?
[ ] Is image/artifact signing required?
[ ] Is distroless/minimal image used or planned?
[ ] Do runbooks assume shell access inside container?
[ ] How are thread dumps and heap dumps captured?
[ ] Does Kubernetes securityContext align with Dockerfile USER?
[ ] Are health probes defined in image, chart, manifest, or platform template?

small enough runtime surface
explicit process command
non-root execution
no secrets
clear traceability
predictable filesystem behavior
stable Java runtime
approved base image
observable startup/shutdown behavior
repeatable build path

buildable by CI
scannable by security tooling
promotable across environments
operable by SRE/platform teams
reviewable by senior engineers
recoverable during incidents

1. Docker image is a production runtime contract, not just packaging.
2. Runtime config and secrets should not be baked into image.
3. Base image choice determines security, patching, and diagnostics posture.
4. Non-root runtime and explicit filesystem writes are default production expectations.
5. ENTRYPOINT must handle signals correctly for graceful shutdown.
6. JAR/WAR/app-server packaging must match actual JAX-RS runtime architecture.
7. Minimal/distroless images improve hardening only if operations can support debugging.
8. Image traceability, scanning, SBOM, signing, and provenance are part of supply chain control.