예시 답변 1
약 100초
리스크 분류·기준 수립 경험 중심으로 푸는 결
졸업 프로젝트에서 `Kubernetes`를 활용한 마이크로서비스 배포 환경을 구성했을 때, 보안 설정을 어디서부터 시작해야 할지 막막했던 경험이 있습니다. 처음에는 기능 동작에 집중했는데, 팀원 중 한 명이 Pod가 기본 설정으로는 다른 네임스페이스 리소스에 접근 가능하다는 점을 지적해줬습니다. 그때부터 RBAC으로 서비스 계정별 권한을 최소화하고, `Network Policy`로 네임스페이스 간 통신을 명시적으로 허용된 경로만 열어두는 방식으로 기준을 잡았습니다. 가장 주의했던 리스크는 컨테이너 이미지에 루트 권한이 기본으로 설정되는 문제였고, securityContext로 runAsNonRoot: true를 설정했습니다. 비밀 값은 환경 변수 하드코딩 대신 Secret 리소스로 분리했습니다. 실무 규모의 환경이 아니라 졸업 프로젝트 수준이었지만, 기본 설정을 그대로 쓰면 의도치 않은 접근이 열린다는 것을 직접 겪으면서 배웠습니다.
이 결의 특징
기본 설정에서 Pod가 다른 네임스페이스에 접근 가능하다는 팀원의 지적을 계기로 RBAC과 Network Policy로 통신 경로를 제한한 흔적이 있습니다. runAsNonRoot 설정과 Secret 리소스 분리까지 구체적 조치가 이어집니다.
이 결이 통하는 자리
보안 설정이 이론이 아니라 실제로 겪은 취약점 지적에서 출발했을 때 통합니다. 기본 설정을 그대로 쓰면 의도치 않은 접근이 열린다는 깨달음이 구체적 조치와 함께 살아 있을 때 면접관이 리스크 감각을 읽는 결이 보입니다.