컨테이너와 레지스트리

OCI(Open Container Initiative): image·runtime·distribution 등 container 상호운용 규격을 정의하는 프로젝트입니다.

OCI image는 manifest, optional index, configuration과 filesystem layer descriptor의 content-addressed graph입니다. container는 이 image를 root filesystem과 실행 설정으로 풀어 namespace·cgroup 등 host 격리 안에서 실행한 process입니다.

image와 container를 동일시하면 writable layer의 변경과 재현 가능한 artifact를 혼동합니다. namespace는 관찰 범위를, cgroup은 resource accounting/limit을 제공하지만 container가 별도 kernel을 갖는 것은 아닙니다.

보안 경계는 image format만으로 생기지 않습니다. runtime config의 capability, seccomp, mount, user와 host kernel 취약성을 함께 봅니다.

교육 사례에서 amd64와 arm64가 함께 있는 image index를 단일 amd64 manifest로 잘못 해석했습니다. index digest와 그 안의 platform manifest digest는 서로 다른 내용을 가리킵니다. 실행 node가 어떤 platform을 선택했는지 확인해야 실제 layer까지 추적할 수 있습니다. container 안에서 만든 파일은 image의 불변 layer와 별개이므로 새 instance에서도 남는다고 가정하지 않습니다.

왜 이런가

image와 container를 동일시하면 writable layer의 변경과 재현 가능한 artifact를 혼동합니다. namespace는 관찰 범위를, cgroup은 resource accounting/limit을 제공하지만 container가 별도 kernel을 갖는 것은 아닙니다.

언제 문제가 되는가

digest·platform·권한 계약 불일치 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

container 내부 UID 0은 host kernel 관점에서 자동으로 안전해지지 않습니다. user namespace와 capability 정책을 별도 확인합니다.

직접 확인하는 방법

image reference를 tag와 digest로 각각 해석합니다. manifest의 platform·config·layer digest를 확인합니다.

SBOM(Software Bill of Materials, software 구성 명세): artifact에 포함된 구성요소를 기술하며 그 자체로 취약점 부재나 신뢰를 보장하지 않습니다.

재현 가능한 build는 source revision, dependency lock, base image digest, builder와 build arguments를 기록해 같은 입력에서 검토 가능한 output을 만드는 과정입니다. SBOM·scan·provenance·signature는 output digest와 연결되어야 합니다.

Dockerfile layer cache는 속도를 높이지만 mutable package index와 secret 유출, 넓은 build context는 재현성과 보안을 해칠 수 있습니다. multi-stage build와 pinned digest, cache/secret mount로 runtime image의 내용을 줄입니다.

scan 결과 0건만 목표로 삼지 않습니다. scanner DB revision, severity policy, exploitability, exception owner와 expiry를 함께 기록합니다.

교육 사례에서 같은 Git commit으로 build했지만 base tag가 바뀌어 output digest가 달라졌습니다. source revision만 같다는 이유로 동일 artifact라고 승인할 수 없습니다. base digest와 dependency lock, builder 정보까지 묶어 변화 원인을 추적합니다. 서명 검증은 누가 어떤 digest에 서명했는지 확인하는 절차이며 취약점 검토와 별도로 수행합니다.

왜 이런가

Dockerfile layer cache는 속도를 높이지만 mutable package index와 secret 유출, 넓은 build context는 재현성과 보안을 해칠 수 있습니다. multi-stage build와 pinned digest, cache/secret mount로 runtime image의 내용을 줄입니다.

언제 문제가 되는가

unpinned base·secret 노출·서명 실패 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

secret을 ARG나 ENV로 전달하면 history 또는 layer에 남을 수 있습니다. BuildKit secret mount와 최소 scope credential을 사용합니다.

직접 확인하는 방법

Git revision·lockfile·base image digest를 build metadata에 넣습니다. network·secret·cache 사용 범위를 build stage별로 확인합니다.

Chain of custody(인계 추적): artifact가 경계를 지날 때 담당자·시각·무결성·승인을 이어 기록하는 절차입니다.

registry는 tag 목록이 아니라 manifest와 blob의 content-addressed graph, 인증·인가·TLS·retention·garbage collection·backup을 운영하는 서비스입니다. 폐쇄망 반입은 각 물리·논리 경계에서 custody와 hash를 증명해야 합니다.

manifest는 여러 blob을 참조하므로 DB와 filesystem을 임의로 따로 backup하면 일관성이 깨질 수 있습니다. retention과 garbage collection은 배포 중인 digest와 rollback window를 고려해야 합니다.

외부에서 검증한 signature가 내부 copy 뒤에도 같은 digest를 가리키는지 확인합니다. 내부 tag 재작성은 가능하지만 승인 identity는 digest로 유지합니다.

교육 사례에서 archive checksum은 맞지만 내부 registry에는 다른 tag의 manifest가 들어갔습니다. media 무결성과 배포 artifact 동일성은 다른 경계의 증거입니다. 반입 archive 검증 뒤 내부 manifest digest도 외부 승인값과 대조해야 합니다. multi-platform image는 모든 manifest와 blob이 포함되어야 하며 하나의 platform만 시험하고 전체 반입 완료로 쓰지 않습니다.

왜 이런가

manifest는 여러 blob을 참조하므로 DB와 filesystem을 임의로 따로 backup하면 일관성이 깨질 수 있습니다. retention과 garbage collection은 배포 중인 digest와 rollback window를 고려해야 합니다.

언제 문제가 되는가

media hash·내부 digest·승인표 불일치 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

archive에 credential file이나 build secret이 섞이지 않았는지 검사합니다. 이동식 media는 조직의 malware scan과 custody 절차를 따릅니다.

직접 확인하는 방법

외부 source registry의 manifest digest와 signature를 저장합니다. export archive와 media의 SHA-256, 담당자, 시각과 봉인 번호를 기록합니다.