KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 09 / 12

운영과 보안

RBAC·secret·backup·restore·upgrade·patch·policy를 변경 관리와 recovery evidence로 연결합니다.

난이도
중급
구성
핵심 단원 4개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    identity·RBAC·secret, backup/restore, canary upgrade, image/workload/network/audit 정책을 단계적으로 적용하고 break-glass까지 검증합니다.

  2. 02

    오늘 맡은 일

    Platform 보안 기준선의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    긴급 장애 중 개발자가 cluster-admin을 요청합니다. 올바른 대응은?

낯선 용어 먼저 풀기

RBAC(Role-Based Access Control, 역할 기반 접근 제어)
subject에 역할을 연결해 허용할 resource와 동작 범위를 정하는 방식입니다.

이 과정의 운영 질문

운영 변경을 최소 권한·복구 가능성·감사 증거와 어떻게 묶을까?

identity·RBAC·secret, backup/restore, canary upgrade, image/workload/network/audit 정책을 단계적으로 적용하고 break-glass까지 검증합니다.

CORE UNIT 1 / 4

Identity와 접근 제어

사람·service account·RBAC의 최소 권한을 설계합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

lab security-admin·break-glass 별도. 관리망과 workload namespace 분리.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Identity와 접근 제어의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Identity와 접근 제어의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Identity와 접근 제어의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Identity와 접근 제어 실습 환경과 안전 경계
하드웨어격리 Kubernetes cluster·backup repository fixture
소프트웨어Kubernetes 1.31 fixture·K3s snapshot·policy engine
필요 권한lab security-admin·break-glass 별도
네트워크관리망과 workload namespace 분리

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes RBAC API rbac.authorization.k8s.io/v1 · K3s v1.31 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장identity에서 확인을 시작합니다
  2. 2장role 계약의 실습 대상을 고정합니다
  3. 3장binding의 출력과 의미를 구분합니다
  4. 4장접근 증거의 진행과 중단을 결정합니다
  5. 5장Identity와 접근 제어의 복구를 재검증합니다
Identity와 접근 제어의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · identity에서 확인을 시작합니다

다음 연결: role 계약의 실습 대상을 고정합니다

  1. identity에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. role 계약의 실습 대상을 고정합니다

    실습 상황:: model-reader service account에 secret 목록 권한 없이 특정 ConfigMap과 Pod log만 허용하는 RBAC를 검토합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 공용 credential·wildcard·owner 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. binding의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 필요 행동은 허용되고 secret 같은 금지 행동은 실제로 거부되는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 접근 증거의 진행과 중단을 결정합니다

    identity inventory, 최소 Role, Binding, allow/deny 시험과 audit 조회를 한 change record에 넣으면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Identity와 접근 제어의 복구를 재검증합니다

    과권한을 찾으면 사용 중인 task를 먼저 확인하고 canary binding으로 축소합니다. 접근 장애가 나면 공용 admin credential 대신 감사되는 break-glass를 쓰고 incident 종료 즉시 회수합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

identity에서 allow·deny audit까지 접근 경계를 검증합니다

RBAC(Role-Based Access Control, 역할 기반 접근 제어): subject에 역할을 연결해 허용할 resource와 동작 범위를 정하는 방식입니다.

authentication은 누구인지, authorization은 무엇을 할 수 있는지 판정합니다. 사람, workload service account, automation과 break-glass identity를 분리해야 credential의 scope·수명·owner를 추적할 수 있습니다.

RBAC 권한은 verb·resource·namespace·resourceName 조합으로 만들어지고 RoleBinding이 subject에 연결합니다. wildcard와 cluster-admin은 새 API가 추가될 때 권한이 예상보다 넓어질 수 있습니다.

최소 권한은 요청 목록을 줄이는 작업이 아니라 실제 업무 task를 allow하고 금지 행동을 deny하는 양방향 시험입니다. auth can-i와 audit log로 확인합니다.

교육 사례에서 log 조회를 위해 cluster-admin을 부여하면 secret 읽기 등 필요 없는 권한도 열립니다. 필요한 동작을 pods/log의 get 권한과 namespace로 좁혀야 합니다. 허용 시험만 통과하면 충분하지 않고 secrets list가 거부되는지도 확인합니다. impersonation 조회를 수행하는 운영자 자신에게도 별도 권한이 필요하므로 시험 실패와 대상 역할의 거부를 구분합니다.

identity inventory와 최소 Role 계약, allow와 deny 두 방향 시험 결과 및 audit 증거를 세 열로 대조한 도표
그림 읽는 법 왼쪽 열에서 사람 운영자·workload service account·automation·break-glass의 type과 owner, 수명을 확인하고, 가운데 열에서 실제 task를 verb·resource·namespace로 분해한 Role과 그것을 subject에 연결한 RoleBinding 출력을 대조합니다. 오른쪽 열의 두 시험은 방향이 반대이며, 허용 시험은 결과가 yes일 때, 금지 시험은 결과가 no일 때 통과입니다. 허용 시험이 no이면 업무가 막히므로 Role을 보완하고, 금지 시험이 yes이면 과권한이므로 여기서 중단합니다. impersonation 조회는 운영자 자신에게도 권한이 필요하므로 시험 자체의 실패와 대상 역할의 거부를 구분해서 읽습니다. 두 요청의 audit event를 찾아 같은 change record에 넣으면 증거가 완성됩니다. 도표의 identity 이름과 출력 문자열은 저자 구성 교육용 예시이며 실제 cluster에서 측정한 값이 아니고, 색을 구별하지 않아도 읽을 수 있습니다. 자료: Kubernetes Using RBAC Authorization · Kubernetes Service Accounts를 바탕으로 저자 구성.
왜 이런가
RBAC 권한은 verb·resource·namespace·resourceName 조합으로 만들어지고 RoleBinding이 subject에 연결합니다. wildcard와 cluster-admin은 새 API가 추가될 때 권한이 예상보다 넓어질 수 있습니다.
언제 문제가 되는가
공용 credential·wildcard·owner 없음 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
service account token과 kubeconfig를 ticket·source repository·shell history에 넣지 않습니다. short-lived credential과 secret store를 사용합니다.
직접 확인하는 방법
identity type·owner·purpose·expiry와 issuer를 inventory합니다. 실제 task를 verb/resource/namespace로 분해합니다.
이 절을 정리하면identity inventory, 최소 Role, Binding, allow/deny 시험과 audit 조회를 한 change record에 넣으면 성공입니다.

CHAPTER 1 / 5

identity에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. identity type·owner·purpose·expiry와 issuer를 inventory합니다. 2. 실제 task를 verb/resource/namespace로 분해합니다. 3. Role/ClusterRole과 Binding의 subject·scope를 추적합니다. 4. 허용 task와 금지 task를 impersonation으로 시험하고 audit event를 찾습니다.

CHAPTER 2 / 5

role 계약의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl auth can-i get configmap/model-config -n inference --as=system:serviceaccount:inference:model-reader
kubectl auth can-i list secrets -n inference --as=system:serviceaccount:inference:model-reader
kubectl get rolebinding -n inference -o wide

CHAPTER 3 / 5

binding의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
yes
no
NAME model-reader SUBJECTS ServiceAccount/model-reader ROLE Role/model-reader

CHAPTER 4 / 5

접근 증거의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Identity와 접근 제어의 복구를 재검증합니다

CONCRETE CASES

model-reader service account에 secret 목록 권한 없이 특정 ConfigMap과 Pod log만 허용하는 RBAC를 검토합니다.

최소 권한은 요청 목록을 줄이는 작업이 아니라 실제 업무 task를 allow하고 금지 행동을 deny하는 양방향 시험입니다. `auth can-i`와 audit log로 확인합니다.

잘못된 대응과 확인할 경계

service account token과 kubeconfig를 ticket·source repository·shell history에 넣지 않습니다. short-lived credential과 secret store를 사용합니다.

과권한을 찾으면 사용 중인 task를 먼저 확인하고 canary binding으로 축소합니다. 접근 장애가 나면 공용 admin credential 대신 감사되는 break-glass를 쓰고 incident 종료 즉시 회수합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: model-reader service account에 secret 목록 권한 없이 특정 ConfigMap과 Pod log만 허용하는 RBAC를 검토합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 공용 credential·wildcard·owner 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

yes
no
NAME model-reader SUBJECTS ServiceAccount/model-reader ROLE Role/model-reader

값 자체를 외우는 것이 아니라 필요 행동은 허용되고 secret 같은 금지 행동은 실제로 거부되는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

service account token과 kubeconfig를 ticket·source repository·shell history에 넣지 않습니다. short-lived credential과 secret store를 사용합니다.

KEY TERMS

이번 단원 핵심 용어

RBAC(Role-Based Access Control, 역할 기반 접근 제어)
subject에 역할을 연결해 허용할 resource와 동작 범위를 정하는 방식입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Identity와 접근 제어의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 4

Backup과 restore

backup 존재가 아니라 격리 restore와 RPO·RTO로 복구 가능성을 검증합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

lab security-admin·break-glass 별도. 관리망과 workload namespace 분리.

3앞 단원 「Identity와 접근 제어」에서 어떤 증거를 남겼습니까?

identity inventory, 최소 Role, Binding, allow/deny 시험과 audit 조회를 한 change record에 넣으면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Backup과 restore의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Backup과 restore의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Backup과 restore의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Backup과 restore 실습 환경과 안전 경계
하드웨어격리 Kubernetes cluster·backup repository fixture
소프트웨어Kubernetes 1.31 fixture·K3s snapshot·policy engine
필요 권한lab security-admin·break-glass 별도
네트워크관리망과 workload namespace 분리

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes RBAC API rbac.authorization.k8s.io/v1 · K3s v1.31 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장복구 목록에서 확인을 시작합니다
  2. 2장backup 생성의 실습 대상을 고정합니다
  3. 3장격리 restore의 출력과 의미를 구분합니다
  4. 4장service 검증의 진행과 중단을 결정합니다
  5. 5장Backup과 restore의 복구를 재검증합니다
Backup과 restore의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 복구 목록에서 확인을 시작합니다

다음 연결: backup 생성의 실습 대상을 고정합니다

  1. 복구 목록에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. backup 생성의 실습 대상을 고정합니다

    실습 상황:: datastore snapshot은 있지만 model artifact와 encryption key가 누락된 recovery plan을 수정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, key·artifact 누락·production 충돌 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 격리 restore의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 같은 recovery point의 state와 artifact가 격리 환경에서 application-ready인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. service 검증의 진행과 중단을 결정합니다

    실측 recovery point·elapsed time·checksum·API acceptance와 누락 dependency를 포함해 RPO/RTO 통과 여부를 판정하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Backup과 restore의 복구를 재검증합니다

    artifact나 key가 누락되면 성공으로 표시하지 않습니다. 복구 목록과 backup job을 보완하고 새 recovery point를 만든 뒤 처음부터 격리 restore를 재실행합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

backup 목록에서 격리 service 복구까지 검증합니다

Recovery point(복구 시점): 검증된 backup에서 실제로 복구할 수 있는 데이터 상태의 시점입니다.

backup은 특정 시점의 복구 재료이고 restore는 그 재료로 service를 다시 사용할 수 있게 만드는 절차입니다. snapshot catalog의 성공 표시만으로 encryption key, 외부 volume, registry artifact와 DNS 의존성이 복원된다고 볼 수 없습니다.

RPO는 허용 가능한 data 손실 시점, RTO는 service 복구 완료 시간입니다. cluster datastore, persistent volume, object artifact, configuration과 secret은 서로 다른 consistency와 retention을 가집니다.

restore 시험은 production에 덮어쓰지 않고 격리 환경에 수행합니다. identity 충돌, external endpoint 호출, credential 재사용을 차단한 뒤 application acceptance를 실행합니다.

교육 사례에서 datastore snapshot은 09:45이지만 model artifact backup은 전날 version입니다. 두 파일이 존재해도 하나의 서비스 revision으로 복구할 수 있는지는 별도 확인이 필요합니다. snapshot이 참조하는 digest와 artifact 목록, key 접근을 함께 맞춥니다. 필요한 외부 데이터가 빠졌다면 snapshot 성공 표시를 그대로 서비스 복구 성공으로 쓰지 않습니다.

복구 재료 네 가지의 recovery point를 시간축에 맞추고 격리 restore 3단계의 증거와 판정으로 RPO와 RTO를 계산하는 도표
그림 읽는 법 위쪽 네 상자를 1번 cluster datastore부터 4번 configuration · secret까지 읽으면 재료마다 source of truth와 backup method, 확인 명령이 다르다는 것을 알 수 있습니다. 가운데 시간축은 model artifact backup이 전날, datastore snapshot이 2026-08-31T09:45:00Z임을 한 줄에 놓은 것이며, 두 재료가 어긋나면 공통 recovery point는 더 오래된 전날 쪽으로 내려갑니다. 아래 세 상자는 격리 restore의 순서이고, 각 상자의 증거는 읽을 명령과 출력, 판정은 진행과 중단을 가르는 기준입니다. 1번에서 production context나 overwrite 가능한 credential이 보이면 여기서 멈춥니다. 2번에서 key나 artifact가 누락되면 snapshot의 성공 표시를 서비스 복구 성공으로 쓰지 않습니다. 3번의 elapsed time으로 RTO를, 실측 recovery point로 RPO를 계산해 통과 여부를 적습니다. 도표의 timestamp·digest·상태 문자열은 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아니고, 물리 배선이나 시간 비율을 그린 그림도 아닙니다. 자료: K3s Backup and Restore · Kubernetes Persistent Volumes를 바탕으로 저자 구성.
왜 이런가
RPO는 허용 가능한 data 손실 시점, RTO는 service 복구 완료 시간입니다. cluster datastore, persistent volume, object artifact, configuration과 secret은 서로 다른 consistency와 retention을 가집니다.
언제 문제가 되는가
key·artifact 누락·production 충돌 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
restore command의 대상 context와 storage endpoint를 두 사람이 교차 확인합니다. production overwrite가 가능한 credential은 lab에서 사용하지 않습니다.
직접 확인하는 방법
service dependency별 source of truth와 backup method를 적습니다. backup timestamp·revision·encryption key·retention·오류를 확인합니다.
이 절을 정리하면실측 recovery point·elapsed time·checksum·API acceptance와 누락 dependency를 포함해 RPO/RTO 통과 여부를 판정하면 성공입니다.

CHAPTER 1 / 5

복구 목록에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. service dependency별 source of truth와 backup method를 적습니다. 2. backup timestamp·revision·encryption key·retention·오류를 확인합니다. 3. 격리 namespace/network에서 datastore와 volume/artifact를 restore합니다. 4. checksum·identity·permission·API test와 elapsed time으로 RPO/RTO를 계산합니다.

CHAPTER 2 / 5

backup 생성의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
sudo k3s etcd-snapshot ls
sha256sum /backup/cluster/snapshot-* /backup/artifacts/model-manifest.json
kubectl --context restore-lab get nodes,pods -A
curl -fsS https://restore-lab.example/health/ready

CHAPTER 3 / 5

격리 restore의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
<snapshot> 2026-08-31T09:45:00Z
<hash> snapshot-...
<hash> model-manifest.json
restore-node Ready
{"status":"ready","model_digest":"sha256:..."}

CHAPTER 4 / 5

service 검증의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Backup과 restore의 복구를 재검증합니다

CONCRETE CASES

datastore snapshot은 있지만 model artifact와 encryption key가 누락된 recovery plan을 수정합니다.

restore 시험은 production에 덮어쓰지 않고 격리 환경에 수행합니다. identity 충돌, external endpoint 호출, credential 재사용을 차단한 뒤 application acceptance를 실행합니다.

잘못된 대응과 확인할 경계

restore command의 대상 context와 storage endpoint를 두 사람이 교차 확인합니다. production overwrite가 가능한 credential은 lab에서 사용하지 않습니다.

artifact나 key가 누락되면 성공으로 표시하지 않습니다. 복구 목록과 backup job을 보완하고 새 recovery point를 만든 뒤 처음부터 격리 restore를 재실행합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: datastore snapshot은 있지만 model artifact와 encryption key가 누락된 recovery plan을 수정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, key·artifact 누락·production 충돌 조건이 보이면 다음 변경으로 넘어가지 마십시오.

<snapshot> 2026-08-31T09:45:00Z
<hash> snapshot-...
<hash> model-manifest.json
restore-node Ready
{"status":"ready","model_digest":"sha256:..."}

값 자체를 외우는 것이 아니라 같은 recovery point의 state와 artifact가 격리 환경에서 application-ready인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

restore command의 대상 context와 storage endpoint를 두 사람이 교차 확인합니다. production overwrite가 가능한 credential은 lab에서 사용하지 않습니다.

KEY TERMS

이번 단원 핵심 용어

Recovery point(복구 시점)
검증된 backup에서 실제로 복구할 수 있는 데이터 상태의 시점입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Backup과 restore의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 4

Upgrade와 변경 관리

canary·drain·중단 기준·rollback을 포함한 변경 계획을 만듭니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

lab security-admin·break-glass 별도. 관리망과 workload namespace 분리.

3앞 단원 「Backup과 restore」에서 어떤 증거를 남겼습니까?

실측 recovery point·elapsed time·checksum·API acceptance와 누락 dependency를 포함해 RPO/RTO 통과 여부를 판정하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Upgrade와 변경 관리의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Upgrade와 변경 관리의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Upgrade와 변경 관리의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Upgrade와 변경 관리 실습 환경과 안전 경계
하드웨어격리 Kubernetes cluster·backup repository fixture
소프트웨어Kubernetes 1.31 fixture·K3s snapshot·policy engine
필요 권한lab security-admin·break-glass 별도
네트워크관리망과 workload namespace 분리

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes RBAC API rbac.authorization.k8s.io/v1 · K3s v1.31 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장변경 계약에서 확인을 시작합니다
  2. 2장canary의 실습 대상을 고정합니다
  3. 3장단계 확대의 출력과 의미를 구분합니다
  4. 4장rollback의 진행과 중단을 결정합니다
  5. 5장Upgrade와 변경 관리의 복구를 재검증합니다
Upgrade와 변경 관리의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 변경 계약에서 확인을 시작합니다

다음 연결: canary의 실습 대상을 고정합니다

  1. 변경 계약에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. canary의 실습 대상을 고정합니다

    실습 상황:: 3-node cluster upgrade plan에 canary·PDB·GPU job drain·rollback acceptance를 추가합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, SLO·error budget·rollback 시간 초과 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 단계 확대의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 control plane readiness·disruption budget·node skew·application rollout이 단계 gate를 통과하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. rollback의 진행과 중단을 결정합니다

    사전 조건, canary 수치, 단계별 Go/No-Go, rollback artifact와 동일 조건 재검증을 change plan에 작성하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Upgrade와 변경 관리의 복구를 재검증합니다

    중단선을 넘으면 신규 단계를 멈추고 canary를 이전 revision으로 되돌립니다. data migration이 있으면 사전 검증된 backward path 또는 snapshot restore를 사용하고 SLO를 다시 측정합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

upgrade는 canary와 중단 기준을 통과하며 확대합니다

Canary(제한된 선행 적용): 대표적인 작은 대상에 변경을 먼저 적용하고 영향을 측정한 뒤 확대하는 절차입니다.

upgrade는 package version 변경이 아니라 사용자 SLO, API compatibility, datastore와 workload를 새 revision으로 옮기는 change입니다. 성공 경로뿐 아니라 중단선과 실제 rollback 가능 시간을 정의해야 합니다.

canary는 대표 traffic과 dependency를 가진 작은 failure domain에서 새 revision의 증거를 얻습니다. drain은 Pod를 이동하지만 PDB·local data·long-running GPU job과 capacity가 준비되지 않으면 가용성을 깨뜨립니다.

변경 전 snapshot이 있다는 사실과 rollback할 수 있다는 사실을 구분합니다. schema 또는 data migration이 backward-compatible한지, 이전 binary가 새 state를 읽을 수 있는지 확인합니다.

교육 사례에서 replica 세 개 중 두 개가 이미 준비되지 않아 PDB가 추가 중단을 허용하지 않았습니다. upgrade 일정이 잡혔다는 이유로 강제 drain하면 남은 가용성을 잃을 수 있습니다. 현재 capacity와 disruption budget을 회복하거나 작업 창을 다시 정해야 합니다. rollback에 이전 binary만 필요한지 이전 state도 필요한지 시험 전부터 구분합니다.

3-node cluster upgrade의 네 단계 gate와 단계마다의 명령·관측값·Go 기준, 오른쪽 No-Go 조건과 되돌리는 경로
그림 읽는 법 위에서 아래로 단계 1 사전 조건, 2 canary, 3 drain, 4 확대 순서로 읽습니다. 각 단계 상자에는 명령과 관측값, 통과로 읽는 Go 기준이 함께 있습니다. 예를 들어 단계 3은 kubectl get pdb -A 가 ALLOWED DISRUPTIONS 1을 보이고 replica 세 개 중 두 개가 준비되어 있어야 다음 단계로 갑니다. 오른쪽 호박색 상자는 같은 줄 단계의 No-Go 조건과 그때 하는 일이며, 조건에 걸리면 아래 단계로 내려가지 않고 그 자리에서 멈춥니다. 아래 파란 상자는 되돌리는 경로로, rollback에 이전 binary만 필요한지 이전 state도 필요한지 시험 전부터 구분하라는 뜻입니다. 초록 화살표는 통과했을 때만 다음 단계로 간다는 순서이며 색을 구별하지 않아도 상자 안 글로 읽을 수 있습니다. 시간 비율이나 물리 배선을 그린 그림은 아닙니다. 도표의 식별자·명령·수치는 저자 구성 교육용 예시이며 실제 장비에서 측정한 결과가 아닙니다. 자료: Kubernetes Version Skew Policy · Kubernetes Rolling Update Deployment를 바탕으로 저자 구성.
왜 이런가
canary는 대표 traffic과 dependency를 가진 작은 failure domain에서 새 revision의 증거를 얻습니다. drain은 Pod를 이동하지만 PDB·local data·long-running GPU job과 capacity가 준비되지 않으면 가용성을 깨뜨립니다.
언제 문제가 되는가
SLO·error budget·rollback 시간 초과 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
모든 node나 control-plane member를 동시에 upgrade하지 않습니다. datastore quorum과 workload capacity를 유지할 순서를 검증합니다.
직접 확인하는 방법
현재/목표 version과 dependency·API version-skew를 고정합니다. backup restore 결과와 package/image rollback artifact를 확인합니다.
이 절을 정리하면사전 조건, canary 수치, 단계별 Go/No-Go, rollback artifact와 동일 조건 재검증을 change plan에 작성하면 성공입니다.

CHAPTER 1 / 5

변경 계약에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 현재/목표 version과 dependency·API version-skew를 고정합니다. 2. backup restore 결과와 package/image rollback artifact를 확인합니다. 3. canary의 error·latency·resource·event를 baseline과 비교합니다. 4. 각 단계의 owner·중단 수치·rollback command와 의사결정 시각을 기록합니다.

CHAPTER 2 / 5

canary의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl get --raw='/readyz?verbose'
kubectl get pdb -A
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion
kubectl rollout status deployment/model-api -n inference --timeout=5m

CHAPTER 3 / 5

단계 확대의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
[+]ping ok
[+]etcd ok
model-api-pdb ALLOWED DISRUPTIONS 1
node-01 v1.31.x
deployment "model-api" successfully rolled out

CHAPTER 4 / 5

rollback의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Upgrade와 변경 관리의 복구를 재검증합니다

CONCRETE CASES

3-node cluster upgrade plan에 canary·PDB·GPU job drain·rollback acceptance를 추가합니다.

변경 전 snapshot이 있다는 사실과 rollback할 수 있다는 사실을 구분합니다. schema 또는 data migration이 backward-compatible한지, 이전 binary가 새 state를 읽을 수 있는지 확인합니다.

잘못된 대응과 확인할 경계

모든 node나 control-plane member를 동시에 upgrade하지 않습니다. datastore quorum과 workload capacity를 유지할 순서를 검증합니다.

중단선을 넘으면 신규 단계를 멈추고 canary를 이전 revision으로 되돌립니다. data migration이 있으면 사전 검증된 backward path 또는 snapshot restore를 사용하고 SLO를 다시 측정합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 3-node cluster upgrade plan에 canary·PDB·GPU job drain·rollback acceptance를 추가합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, SLO·error budget·rollback 시간 초과 조건이 보이면 다음 변경으로 넘어가지 마십시오.

[+]ping ok
[+]etcd ok
model-api-pdb ALLOWED DISRUPTIONS 1
node-01 v1.31.x
deployment "model-api" successfully rolled out

값 자체를 외우는 것이 아니라 control plane readiness·disruption budget·node skew·application rollout이 단계 gate를 통과하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

모든 node나 control-plane member를 동시에 upgrade하지 않습니다. datastore quorum과 workload capacity를 유지할 순서를 검증합니다.

KEY TERMS

이번 단원 핵심 용어

Canary(제한된 선행 적용)
대표적인 작은 대상에 변경을 먼저 적용하고 영향을 측정한 뒤 확대하는 절차입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Upgrade와 변경 관리의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 4 / 4

Platform 보안 기준선

image·workload·network·audit policy를 단계적으로 적용합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

lab security-admin·break-glass 별도. 관리망과 workload namespace 분리.

3앞 단원 「Upgrade와 변경 관리」에서 어떤 증거를 남겼습니까?

사전 조건, canary 수치, 단계별 Go/No-Go, rollback artifact와 동일 조건 재검증을 change plan에 작성하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Platform 보안 기준선의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Platform 보안 기준선의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Platform 보안 기준선의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Platform 보안 기준선 실습 환경과 안전 경계
하드웨어격리 Kubernetes cluster·backup repository fixture
소프트웨어Kubernetes 1.31 fixture·K3s snapshot·policy engine
필요 권한lab security-admin·break-glass 별도
네트워크관리망과 workload namespace 분리

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes RBAC API rbac.authorization.k8s.io/v1 · K3s v1.31 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장artifact에서 확인을 시작합니다
  2. 2장workload의 실습 대상을 고정합니다
  3. 3장network의 출력과 의미를 구분합니다
  4. 4장감사·대응의 진행과 중단을 결정합니다
  5. 5장Platform 보안 기준선의 복구를 재검증합니다
Platform 보안 기준선의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · artifact에서 확인을 시작합니다

다음 연결: workload의 실습 대상을 고정합니다

  1. artifact에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. workload의 실습 대상을 고정합니다

    실습 상황:: privileged·hostPath·무제한 egress를 가진 inference Pod를 단계적으로 restricted baseline으로 옮깁니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 미소유 예외·secret 노출·deny 회귀 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. network의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 workload 권한·network·interactive exec 경계가 policy 의도와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 감사·대응의 진행과 중단을 결정합니다

    현재 gap, dry-run 영향, canary 적용, allow/deny와 audit 증거, rollback과 예외 만료를 포함한 baseline report를 만들면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Platform 보안 기준선의 복구를 재검증합니다

    정상 traffic이 끊기면 전체 정책을 삭제하기보다 canary revision을 rollback하고 관측된 tuple을 검토합니다. 최소 allow rule을 source-controlled change로 추가하고 거부 시험도 반복합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

artifact에서 audit까지 겹친 보안 경계를 검증합니다

Default deny(기본 거부): 명시적으로 허용한 경로 외의 접근을 차단하는 정책 원칙입니다.

platform 보안은 하나의 scanner가 아니라 artifact identity, workload 권한, network reachability, secret, node, audit의 겹친 경계입니다. 한 계층이 우회되어도 다른 계층이 blast radius와 탐지 시간을 줄여야 합니다.

default-deny network policy와 restricted workload policy는 강력하지만 현재 traffic·capability 의존성을 관찰하지 않고 즉시 강제하면 정상 service를 끊습니다. audit/dry-run, canary, 예외 owner·expiry를 거쳐 확대합니다.

정책 수보다 실제 allow/deny 시험과 탐지 증거가 중요합니다. image digest·signature, non-root·capability·seccomp, egress, secret mount와 audit event를 release revision에 연결합니다.

교육 사례에서 egress 기본 거부를 적용하면서 DNS 허용 규칙을 빠뜨렸습니다. runtime은 살아 있지만 model storage 이름을 해석하지 못해 요청이 실패했습니다. 정책 전체를 삭제하면 차단하려던 무관한 경로까지 열립니다. 관측된 DNS와 storage 의존성만 최소 범위로 허용한 뒤 금지 경로가 여전히 거부되는지 함께 시험합니다.

artifact identity부터 audit까지 겹친 다섯 경계와 겹마다의 확인 명령·통과 값, 그 겹만 뚫렸을 때 남는 방어
그림 읽는 법 바깥 겹 1 artifact identity에서 안쪽 겹 5 audit까지 순서대로 읽습니다. 겹마다 확인 명령과 통과로 읽는 값이 적혀 있어, 예를 들어 겹 2는 securityContext에 runAsNonRoot true와 capabilities drop ALL이 보이면 통과입니다. 오른쪽 상자는 그 겹만 뚫렸을 때 남는 방어이며, 안쪽으로 갈수록 남는 겹이 줄어듭니다. 아래 사례는 egress 기본 거부에 DNS 허용 규칙을 빠뜨렸을 때의 증상, 정책 전체를 삭제하는 잘못된 조치, 관측된 의존성만 최소 범위로 허용하는 올바른 조치를 왼쪽에서 오른쪽으로 보여 줍니다. 붉은 상자의 세 조건인 미소유 예외·secret 노출·deny 회귀는 하나만 보여도 다음 변경으로 넘어가지 않는다는 뜻이며 색을 구별하지 않아도 읽을 수 있습니다. 겹의 크기는 위험의 크기가 아니라 포함 관계와 확인 순서만 나타냅니다. 도표 안의 식별자·명령·값은 저자 구성 교육용 예시이며 실제 장비에서 측정한 결과가 아닙니다. 자료: Kubernetes Network Policies · Kubernetes Pod Security Standards · Kubernetes Using RBAC Authorization를 바탕으로 저자 구성.
왜 이런가
default-deny network policy와 restricted workload policy는 강력하지만 현재 traffic·capability 의존성을 관찰하지 않고 즉시 강제하면 정상 service를 끊습니다. audit/dry-run, canary, 예외 owner·expiry를 거쳐 확대합니다.
언제 문제가 되는가
미소유 예외·secret 노출·deny 회귀 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
보안 정책을 우회하려고 privileged나 hostPath를 임시 추가하고 방치하지 않습니다. 예외에는 owner·사유·범위·expiry와 보완 통제가 필요합니다.
직접 확인하는 방법
배포 image digest와 signature policy 결과를 확인합니다. runAsNonRoot·capability drop·seccomp·readOnlyRootFilesystem을 봅니다.
이 절을 정리하면현재 gap, dry-run 영향, canary 적용, allow/deny와 audit 증거, rollback과 예외 만료를 포함한 baseline report를 만들면 성공입니다.

CHAPTER 1 / 5

artifact에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 배포 image digest와 signature policy 결과를 확인합니다. 2. runAsNonRoot·capability drop·seccomp·readOnlyRootFilesystem을 봅니다. 3. namespace별 ingress/egress allow list와 DNS·registry 의존성을 측정합니다. 4. 허용/거부 시험과 audit event, exception owner·expiry를 연결합니다.

CHAPTER 2 / 5

workload의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl get pod -n inference model-api -o jsonpath='{.spec.securityContext}{"\n"}{.spec.containers[0].securityContext}{"\n"}'
kubectl get networkpolicy -n inference -o yaml
kubectl auth can-i create pods/exec -n inference --as=system:serviceaccount:inference:model-api

CHAPTER 3 / 5

network의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
{"runAsNonRoot":true,"seccompProfile":{"type":"RuntimeDefault"}}
{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]}}
... default-deny ...
no

CHAPTER 4 / 5

감사·대응의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Platform 보안 기준선의 복구를 재검증합니다

CONCRETE CASES

privileged·hostPath·무제한 egress를 가진 inference Pod를 단계적으로 restricted baseline으로 옮깁니다.

정책 수보다 실제 allow/deny 시험과 탐지 증거가 중요합니다. image digest·signature, non-root·capability·seccomp, egress, secret mount와 audit event를 release revision에 연결합니다.

잘못된 대응과 확인할 경계

보안 정책을 우회하려고 privileged나 hostPath를 임시 추가하고 방치하지 않습니다. 예외에는 owner·사유·범위·expiry와 보완 통제가 필요합니다.

정상 traffic이 끊기면 전체 정책을 삭제하기보다 canary revision을 rollback하고 관측된 tuple을 검토합니다. 최소 allow rule을 source-controlled change로 추가하고 거부 시험도 반복합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: privileged·hostPath·무제한 egress를 가진 inference Pod를 단계적으로 restricted baseline으로 옮깁니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 미소유 예외·secret 노출·deny 회귀 조건이 보이면 다음 변경으로 넘어가지 마십시오.

{"runAsNonRoot":true,"seccompProfile":{"type":"RuntimeDefault"}}
{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]}}
... default-deny ...
no

값 자체를 외우는 것이 아니라 workload 권한·network·interactive exec 경계가 policy 의도와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

보안 정책을 우회하려고 privileged나 hostPath를 임시 추가하고 방치하지 않습니다. 예외에는 owner·사유·범위·expiry와 보완 통제가 필요합니다.

KEY TERMS

이번 단원 핵심 용어

Default deny(기본 거부)
명시적으로 허용한 경로 외의 접근을 차단하는 정책 원칙입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Platform 보안 기준선의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

긴급 장애 중 개발자가 cluster-admin을 요청합니다. 올바른 대응은?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

RBAC에서 RoleBinding이 하는 일은?

답 선택
적용 문제 2

RPO 15분, RTO 60분의 뜻은?

답 선택
종합 문제 3

정책을 production에 적용하는 안전한 순서는?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.