Red Hat OpenShift에서 Docker Hardened Images 사용하기

Red Hat OpenShift에서 Docker Hardened Images 사용하기 (Use Docker Hardened Images with Red Hat OpenShift)

Red Hat OpenShift에 Docker Hardened Images(DHI)를 배포하고, Security Context Constraints를 구성하며, 임의 사용자 ID 배정과 런타임·개발 이미지 변형 모두에 대한 파일 권한 설정을 다루는 방법을 배우는 가이드예요.

출처: 문서

본문

Docker Hardened Images(DHI)는 Red Hat OpenShift Container Platform에 배포할 수 있어요. 하지만 OpenShift의 보안 모델은 표준 Kubernetes와 달라서 특정 구성을 요구해요. OpenShift는 이미지의 기본 사용자 ID 대신 임의로 배정된 사용자 ID로 컨테이너를 실행하기 때문에, 쓰기 가능한 경로가 접근 가능하게 유지되도록 Dockerfile에서 파일 소유권과 그룹 권한을 조정해야 해요.

이 가이드는 Security Context Constraints(SCC), 임의 사용자 ID 배정, 파일 권한 요구사항, 런타임·개발 이미지 변형 모두에 대한 모범 사례를 다루며 OpenShift 환경에서 Docker Hardened Images를 배포하는 방법을 설명해요.

OpenShift 보안이 Kubernetes와 다른 이유 (How OpenShift security differs from Kubernetes)

OpenShift는 Security Context Constraints(SCC)로 Kubernetes를 확장해요. SCC는 파드가 수행할 수 있는 작업과 접근할 수 있는 리소스를 제어해요. 바닐라 Kubernetes는 유사한 목적으로 Pod Security Standards(PSS)를 사용하지만, SCC는 더 세분화되어 있고 기본적으로 강제됩니다.

DHI 배포에 영향을 주는 핵심 차이점:

• 임의 사용자 ID(Arbitrary user IDs). 기본적으로 OpenShift는 각 프로젝트에 할당된 범위에서 임의로 배정된 사용자 ID(UID)로 컨테이너를 실행해요. 기본 restricted-v2 SCC(OpenShift 4.11에서 도입)는 MustRunAsRange 전략을 사용하는데, 이는 컨테이너 이미지의 USER 지시문을 프로젝트의 할당된 범위(일반적으로 1000000000보다 높게 시작)의 UID로 덮어써요. 이는 DHI 이미지가 비-root 사용자(UID 65532)를 지정하더라도 OpenShift가 다른 예측 불가능한 UID로 컨테이너를 실행한다는 뜻이에요.
• 루트 그룹 요구사항(Root group requirement). OpenShift는 임의 UID를 루트 그룹(GID 0)에 배정해요. 컨테이너 프로세스는 항상 gid=0(root)로 실행됩니다. 프로세스가 써야 하는 모든 디렉터리나 파일은 루트 그룹(GID 0)이 소유하고 그룹 읽기/쓰기 권한이 있어야 해요. 이것은 Red Hat의 이미지 생성 가이드라인에 문서화되어 있어요.

중요: DHI 이미지는 기본적으로 파일 소유권을 nonroot:nonroot(65532:65532)로 설정해요. OpenShift 임의 UID는 nonroot 그룹(65532)에 없으므로, 파드가 SCC에 의해 승인되고 컨테이너가 시작되더라도 그 파일들에 쓸 수 없어요. 쓰기 가능한 모든 경로의 그룹 소유권을 GID 0으로 변경해야 해요. 이것이 OpenShift에서 DHI를 배포할 때 권한 오류의 가장 흔한 원인입니다.

• 기능 제한(Capability restrictions). restricted-v2 SCC는 기본적으로 모든 Linux 기능을 드롭하고 allowPrivilegeEscalation: false, runAsNonRoot: true, RuntimeDefault 유형의 seccompProfile을 강제해요. DHI 런타임 이미지는 비-root 사용자로 실행되고 상승된 기능을 요구하지 않으므로 이미 이러한 제약을 충족합니다.

DHI 이미지를 OpenShift로 가져오기 (Pull DHI images into OpenShift)

배포 전에 OpenShift 클러스터가 DHI 레지스트리 또는 Docker Hub의 미러링된 리포지토리에 인증할 수 있도록 이미지 풀 시크릿(image pull secret)을 만드세요.

이미지 풀 시크릿 만들기

oc create secret docker-registry dhi-pull-secret \
  --docker-server=docker.io \
  --docker-username=<your-docker-username> \
  --docker-password=<your-docker-access-token> \
  --docker-email=<your-email>

미러링된 리포지토리 대신 dhi.io에서 직접 가져온다면 --docker-server=dhi.io로 설정하세요.

시크릿을 서비스 계정에 연결하기

프로젝트의 기본 서비스 계정에 풀 시크릿을 연결해서 모든 배포가 DHI 이미지를 자동으로 가져올 수 있게 하세요:

oc secrets link default dhi-pull-secret --for=pull

특정 서비스 계정과 시크릿을 사용하려면:

oc secrets link <service-account-name> dhi-pull-secret --for=pull

DHI에서 OpenShift 호환 이미지 빌드하기 (Build OpenShift-compatible images from DHI)

DHI 런타임 이미지는 distroless입니다 — 셸도, 패키지 관리자도, RUN 가능 환경도 없어요. 즉, Dockerfile의 런타임 스테이지에서 RUN 명령을 사용할 수 없어요. OpenShift를 위한 모든 파일 권한 조정은 -dev 빌드 스테이지에서 수행하고, 그 결과를 COPY --chown으로 런타임 스테이지로 복사해야 해요.

OpenShift 호환성의 핵심 패턴:

• DHI -dev 변형을 빌드 스테이지로 사용하세요(셸이 있음).
• 빌드 스테이지에서 애플리케이션을 빌드하고 GID 0 소유권을 설정하세요.
• COPY --chown=<UID>:0으로 결과를 DHI 런타임 이미지로 복사하세요.

예시: OpenShift용 Nginx

# Build stage — has a shell, can run commands
FROM YOUR_ORG/dhi-nginx:1.29-alpine3.23-dev AS build
# Copy custom config and set root group ownership
COPY nginx.conf /tmp/nginx.conf
COPY default.conf /tmp/default.conf
# Prepare writable directories with GID 0
# (Nginx needs to write to cache, logs, and PID file locations)
RUN mkdir -p /tmp/nginx-cache /tmp/nginx-run && \
    chgrp -R 0 /tmp/nginx-cache /tmp/nginx-run && \
    chmod -R g=u /tmp/nginx-cache /tmp/nginx-run

# Runtime stage — distroless, NO shell, NO RUN commands
FROM YOUR_ORG/dhi-nginx:1.29-alpine3.23
COPY --from=build --chown=65532:0 /tmp/nginx.conf /etc/nginx/nginx.conf
COPY --from=build --chown=65532:0 /tmp/default.conf /etc/nginx/conf.d/default.conf
COPY --from=build --chown=65532:0 /tmp/nginx-cache /var/cache/nginx
COPY --from=build --chown=65532:0 /tmp/nginx-run /var/run

중요: 파일을 런타임 스테이지로 복사할 때는 항상 --chown=<UID>:0(user:root-group)을 사용하세요. 이렇게 하면 OpenShift가 배정한 임의 UID가 루트 그룹 멤버십을 통해 파일에 접근할 수 있어요. 런타임 스테이지에서 RUN을 절대 사용하지 마세요 — distroless DHI 이미지에는 셸이 없어요.

참고: DHI 이미지의 UID는 이미지마다 달라요. 대부분은 65532(nonroot)를 사용하지만, 일부(Node.js 이미지 같은)는 다른 UID를 사용할 수 있어요. 다음으로 확인하세요: docker inspect dhi.io/<image>:<tag> --format '{{.Config.User}}'

OpenShift에 배포하세요:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dhi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-dhi
  template:
    metadata:
      labels:
        app: nginx-dhi
    spec:
      containers:
        - name: nginx
          image: YOUR_ORG/dhi-nginx:1.29-alpine3.23
          ports:
            - containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
            capabilities:
              drop:
                - ALL
      imagePullSecrets:
        - name: dhi-pull-secret

DHI Nginx는 기본적으로 (80이 아닌) 8080 포트에서 수신 대기하는데, 이는 비-root 요구사항과 호환돼요. SCC 변경은 필요 없습니다.

예시: OpenShift용 Node.js 애플리케이션

# Build stage — dev variant has shell and npm
FROM YOUR_ORG/dhi-node:24-alpine3.23-dev AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Set GID 0 on everything the runtime needs to write
RUN chgrp -R 0 /app/dist /app/node_modules && \
    chmod -R g=u /app/dist /app/node_modules

# Runtime stage — distroless, NO shell
FROM YOUR_ORG/dhi-node:24-alpine3.23
WORKDIR /app
COPY --from=build --chown=65532:0 /app/dist ./dist
COPY --from=build --chown=65532:0 /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

배포하세요:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
        - name: app
          image: YOUR_ORG/dhi-node-app:latest
          ports:
            - containerPort: 3000
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
            capabilities:
              drop:
                - ALL
      imagePullSecrets:
        - name: dhi-pull-secret

임의 사용자 ID 처리하기 (Handle arbitrary user IDs)

OpenShift의 restricted-v2 SCC는 컨테이너 프로세스에 임의 UID를 배정해요. 이 UID는 이미지 안의 /etc/passwd에 존재하지 않지만 컨테이너는 그래도 실행됩니다 — 프로세스에 연관된 사용자 이름이 없을 뿐이에요.

이것은 다음과 같은 애플리케이션에 문제를 일으킬 수 있어요:

• 현재 사용자의 홈 디렉터리나 사용자 이름을 조회하는 경우
• 특정 UID가 소유한 디렉터리에 쓰는 경우
• 실행 중인 사용자를 위해 /etc/passwd를 확인하는 경우

임의 UID에 대한 passwd 항목 추가하기

일부 애플리케이션(특히 특정 Python 또는 Java 라이브러리를 사용하는 것들)은 실행 중인 사용자에 대한 유효한 /etc/passwd 항목을 요구해요. 래퍼 엔트리포인트 스크립트로 처리할 수 있어요.

이 패턴은 셸을 필요로 하므로 DHI -dev 변형 또는 셸을 포함한 DHI Enterprise 커스터마이즈된 이미지에서만 동작해요. 빌드 스테이지에서 이미지를 준비하세요:

FROM YOUR_ORG/dhi-python:3.13-alpine3.23-dev AS build
# ... build your application ...
# Make /etc/passwd group-writable so the entrypoint can append to it
RUN chgrp 0 /etc/passwd && chmod g=u /etc/passwd
# Create the entrypoint wrapper
RUN printf '#!/bin/sh\n\
if ! whoami > /dev/null 2>&1; then\n\
if [ -w /etc/passwd ]; then\n\
echo "${USER_NAME:-appuser}:x:$(id -u):0:dynamic user:/tmp:/sbin/nologin" >> /etc/passwd\n\
fi\n\
fi\n\
exec "$@"\n' > /entrypoint.sh && chmod +x /entrypoint.sh

# This pattern requires a -dev variant as runtime (has shell)
FROM YOUR_ORG/dhi-python:3.13-alpine3.23-dev
COPY --from=build --chown=65532:0 /app ./app
COPY --from=build --chown=65532:0 /entrypoint.sh /entrypoint.sh
COPY --from=build --chown=65532:0 /etc/passwd /etc/passwd
USER 65532
ENTRYPOINT ["/entrypoint.sh"]
CMD ["python", "app/main.py"]

참고: distroless 런타임 이미지(셸 없음)에서는 passwd-주입 패턴이 불가능합니다. 대신 다음 섹션에서 설명하는 nonroot SCC를 사용해 이미지의 내장 UID로 실행해서 기존 /etc/passwd 항목이 실행 프로세스와 일치하게 하세요. 또는 대부분의 경우 OpenShift 4.x가 임의 UID를 /etc/passwd에 자동으로 주입하므로 많은 애플리케이션에서 이 문제가 해결돼요.

고정 UID에는 non-root SCC 사용하기

애플리케이션이 이미지에 정의된 특정 UID(보통 DHI의 경우 65532)로 실행되도록 요구한다면 기본 restricted-v2 대신 nonroot SCC를 사용할 수 있어요. nonroot SCC는 MustRunAsNonRoot 전략을 사용하는데, 이는 0이 아닌 모든 UID를 허용해요.

중요: nonroot SCC가 동작하려면 이미지의 USER 지시문이 nonroot 같은 사용자 이름 문자열이 아닌 숫자 UID(예: 65532)를 지정해야 해요. OpenShift는 사용자 이름이 0이 아닌 UID에 매핑되는지 확인할 수 없어요. DHI 이미지를 다음으로 확인하세요: docker inspect YOUR_ORG/dhi-node:24-alpine3.23 --format '{{.Config.User}}'. 출력이 숫자가 아닌 문자열이라면 파드 스펙에서 runAsUser를 명시적으로 설정하세요.

서비스 계정을 만들고 nonroot SCC를 부여하세요:

oc create serviceaccount dhi-nonroot
oc adm policy add-scc-to-user nonroot -z dhi-nonroot

배포에서 서비스 계정을 참조하세요:

spec:
  template:
    spec:
      serviceAccountName: dhi-nonroot
      containers:
        - name: app
          image: YOUR_ORG/dhi-node:24-alpine3.23
          securityContext:
            runAsUser: 65532
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            seccompProfile:
              type: RuntimeDefault
            capabilities:
              drop:
                - ALL

배포 후 SCC 배정을 확인하세요:

oc get pod <pod-name> -o jsonpath='{.metadata.annotations.openshift\.io/scc}'

이것은 nonroot를 반환해야 해요.

고정 UID와 함께 nonroot SCC를 사용하면 프로세스가 65532(이미지의 파일 소유권과 일치)로 실행되므로, 이미 65532가 소유한 경로에는 GID 0 조정이 반드시 필요하지는 않아요. 하지만 restricted-v2와 nonroot SCC 양쪽 모두에서 이식성을 위해 chown <UID>:0을 적용하는 것이 여전히 권장돼요.

OpenShift에서 DHI dev 변형 사용하기 (Use DHI dev variants in OpenShift)

DHI -dev 변형에는 셸, 패키지 관리자, 개발 도구가 포함돼요. 기본적으로 루트(UID 0)로 실행되는데, 이는 OpenShift의 restricted-v2 SCC와 충돌해요. 세 가지 접근 방식이 있습니다:

옵션 1: dev 변형을 빌드 스테이지에서만 사용하기(권장)

-dev 변형을 Dockerfile 빌드 스테이지에서만 사용하고 OpenShift에 직접 배포하지 마세요:

FROM YOUR_ORG/dhi-node:24-alpine3.23-dev AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Set root group ownership for OpenShift compatibility
RUN chgrp -R 0 /app/dist /app/node_modules && \
    chmod -R g=u /app/dist /app/node_modules

FROM YOUR_ORG/dhi-node:24-alpine3.23
WORKDIR /app
COPY --from=build --chown=65532:0 /app/dist ./dist
COPY --from=build --chown=65532:0 /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

최종 런타임 이미지는 non-root이고 distroless이며 restricted-v2와 완전히 호환됩니다.

옵션 2: 디버깅을 위해 anyuid SCC 부여하기

디버깅을 위해 OpenShift에서 -dev 변형을 직접 실행해야 한다면 전용 서비스 계정에 anyuid SCC를 부여하세요:

oc create serviceaccount dhi-debug
oc adm policy add-scc-to-user anyuid -z dhi-debug

그런 다음 파드에서 참조하세요:

apiVersion: v1
kind: Pod
metadata:
  name: dhi-debug
spec:
  serviceAccountName: dhi-debug
  containers:
    - name: debug
      image: YOUR_ORG/dhi-node:24-alpine3.23-dev
      command: ["sleep", "infinity"]
  imagePullSecrets:
    - name: dhi-pull-secret

중요: anyuid SCC는 root를 포함한 모든 UID로 실행을 허용해요. 임시 디버깅에만 사용하고 — 프로덕션 워크로드에서는 절대 사용하지 마세요.

옵션 3: oc debug 또는 임시 컨테이너 사용하기

셸이 없는 distroless 런타임 이미지의 경우, docker debug(OpenShift의 CRI-O가 아닌 Docker Engine에서만 동작) 대신 OpenShift 네이티브 디버깅 도구를 사용하세요.

oc debug로 디버그 셸이 있는 파드 사본을 만드세요:

# Create a debug pod based on a deployment
oc debug deployment/nginx-dhi
# Override the image to use a -dev variant with a shell
oc debug deployment/nginx-dhi --image=YOUR_ORG/dhi-node:24-alpine3.23-dev

임시 컨테이너(OpenShift 4.12+ / Kubernetes 1.25+)를 사용하세요:

kubectl debug -it <pod-name> --image=YOUR_ORG/dhi-node:24-alpine3.23-dev \
  --target=app -- sh

이것은 파드를 재시작하지 않고 실행 중인 파드에 임시 디버그 컨테이너를 붙이며, 파드의 프로세스 네임스페이스를 공유해요.

참고: docker debug는 로컬 개발용 Docker Desktop/CLI 기능이에요. 컨테이너 런타임으로 CRI-O를 사용하는 OpenShift 클러스터에서는 사용할 수 없어요.

OpenShift에 DHI Helm 차트 배포하기 (Deploy DHI Helm charts on OpenShift)

DHI는 인기 있는 애플리케이션용으로 미리 구성된 Helm 차트를 제공해요. 이 차트들을 OpenShift에 배포할 때는 보안 컨텍스트 설정을 조정해야 할 수 있어요.

차트 값 먼저 확인하기 (Inspect chart values first)

설치 전에 차트가 노출하는 보안 컨텍스트 값을 확인하세요:

helm registry login dhi.io
helm show values oci://dhi.io/<chart-name> --version <version> | grep -A 20 securityContext

사용 가능한 값 경로는 차트마다 다르므로, 오버라이드를 설정하기 전에 항상 values.yaml을 확인하세요.

OpenShift 오버라이드로 설치하기 (Install with OpenShift overrides)

다음 예시는 일반적인 설치 패턴을 보여줘요. 특정 차트에 대해 helm show values가 반환하는 내용에 따라 --set 경로를 조정하세요:

helm install my-release oci://dhi.io/<chart-name> \
  --version <version> \
  --set "imagePullSecrets[0].name=dhi-pull-secret" \
  -f openshift-values.yaml

차트에 적합한 보안 컨텍스트 오버라이드가 있는 openshift-values.yaml을 만드세요:

# Example — adjust keys based on `helm show values` output
podSecurityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

참고: DHI Helm 차트 값 경로는 차트 간에 표준화되어 있지 않아요. 예를 들어 한 차트는 image.imagePullSecrets를 사용하고 다른 차트는 global.imagePullSecrets를 사용할 수 있어요. 항상 해당 차트의 문서나 values.yaml을 확인하세요.

배포 확인하기 (Verify your deployment)

DHI 이미지를 OpenShift에 배포한 후 보안 구성을 확인하세요.

배정된 SCC 확인하기

oc get pods -o 'custom-columns=NAME:.metadata.name,SCC:.metadata.annotations.openshift\.io/scc'

런타임 DHI 이미지는 restricted-v2(또는 구성했다면 nonroot)를 보여줘야 해요.

실행 중인 UID 확인하기

oc exec <pod-name> -- id

restricted-v2 SCC를 사용하면 다음 같은 출력이 보일 거예요:

uid=1000650000 gid=0(root) groups=0(root),1000650000

UID는 프로젝트의 할당된 범위에서 나오고, 기본 GID는 항상 0(루트 그룹)이에요. nonroot SCC와 runAsUser: 65532를 사용하면 uid=65532가 보일 거예요.

이미지가 distroless인지 확인하기

oc exec <pod-name> -- sh -c "echo hello"

런타임(비-dev) DHI 이미지에서는 이 명령이 $PATH에서 sh를 찾을 수 없다는 오류와 함께 실패해야 해요. 정확한 오류 형식은 CRI-O 버전에 따라 달라요.

배포된 이미지 스캔하기

Docker Scout를 사용해 배포된 이미지의 보안 자세를 확인하세요(클러스터가 아닌 로컬 머신에서 실행):

docker scout cves YOUR_ORG/dhi-nginx:1.29-alpine3.23
docker scout quickview YOUR_ORG/dhi-nginx:1.29-alpine3.23

일반적인 문제와 해결책 (Common issues and solutions)

• 파드가 "container has runAsNonRoot and image has group or user ID set to root" 오류로 시작하지 않음. 이것은 기본 restricted-v2 SCC로 DHI -dev 변형을 배포할 때 발생해요. 대신 런타임 변형을 사용하거나, 서비스 계정에 anyuid SCC를 부여하세요.
• 애플리케이션이 디렉터리에 쓸 수 없음. OpenShift가 배정한 임의 UID에 쓰기 권한이 없어요. 이것은 OpenShift에서 DHI의 가장 흔한 문제입니다. 모든 쓰기 가능 경로는 GID 0이 소유하고 그룹 쓰기 권한이 있어야 해요. 빌드 스테이지에서 다음으로 수정하세요: chgrp -R 0 /path && chmod -R g=u /path, 그런 다음 COPY --chown=<UID>:0으로 런타임 스테이지로 복사하세요.
• 애플리케이션이 "user not found" 또는 "no matching entries in passwd file" 오류로 실패함. 일부 애플리케이션은 유효한 /etc/passwd 항목이 필요해요. 대부분의 경우 OpenShift 4.x가 임의 UID를 /etc/passwd에 자동으로 주입해요. 애플리케이션이 여전히 실패하면 passwd-주입 패턴(-dev 변형 필요)을 사용하거나, nonroot SCC로 이미지의 내장 UID로 실행하세요.
• 파드가 80 또는 443 포트에 바인딩하지 못함. 1024 미만의 포트는 루트 권한이 필요해요. DHI 이미지는 기본적으로 비특권 포트를 사용해요(예: Nginx는 8080 사용). OpenShift Service를 구성해 외부 포트를 컨테이너의 비특권 포트에 매핑하세요:

apiVersion: v1
kind: Service
metadata:
  name: nginx-dhi
spec:
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: nginx-dhi

• "unauthorized: authentication required"와 함께 ImagePullBackOff. 풀 시크릿이 올바르게 구성되고 서비스 계정에 연결됐는지 확인하세요. oc get secret dhi-pull-secret와 oc describe sa default로 확인하세요.
• 런타임 스테이지에서 "exec: not found"로 Dockerfile 빌드 실패. distroless 런타임 스테이지에서 RUN을 사용하고 있어요. DHI 런타임 이미지에는 셸이 없으므로 RUN 명령이 실행될 수 없어요. 모든 RUN 명령을 -dev 빌드 스테이지로 옮기고 COPY --chown으로 결과를 전달하세요.

DHI와 OpenShift 호환성 요약 (DHI and OpenShift compatibility summary)

기능	DHI runtime	DHI -dev	DHI with Enterprise customization
Default SCC (restricted-v2)	Yes, with GID 0 permissions	Requires anyuid	Yes, with GID 0 permissions
Non-root by default	Yes (UID 65532)	No (root)	Yes (configurable UID)
Arbitrary UID support	Yes, with chown <UID>:0	Yes	Yes, with chown <UID>:0
Distroless (no shell)	Yes — no RUN in Dockerfile	No	Yes — no RUN in Dockerfile
Unprivileged ports	Yes (higher than 1024)	Configurable	Yes (higher than 1024)
SLSA Build Level 3	Yes	Yes	Yes
Debug on cluster	oc debug / ephemeral containers	oc exec with shell	oc debug / ephemeral containers

다음 단계 (What's next)

• Use an image in Kubernetes — 일반적인 DHI Kubernetes 배포 가이드.
• Customize an image — Enterprise 커스터마이제이션으로 DHI 이미지에 패키지 추가하기.
• Debug a container — Docker Debug로 distroless 컨테이너 문제 해결하기(로컬 개발).
• Managing SCCs — Security Context Constraints에 대한 Red Hat 참조 문서.
• Creating images for OpenShift — OpenShift 호환 컨테이너 이미지 구축에 대한 Red Hat 가이드라인.