사람은 Central Auth로, 프로그램은 API Key로 들어오게 한 이유

Task Hub는 처음에는 Vue로 만든 운영 화면에서 내가 직접 작업을 등록하고 상태를 확인하는 도구였다. 그런데 ChatGPT 같은 외부 프로그램에서도 같은 Task API를 직접 호출해서 작업을 등록하고 진행 상태를 물어보게 만들 필요가 생겼다. 화면 하나만 상대하던 API를, 사람과 프로그램이 같이 두드리는 API로 넓히는 일이었다.처음 생각은 단순했다. 이미 Central Auth라는 중앙 인증이 있으니, 그걸 그대로 확장해서 인증 경로를 하나로 통일하면 되겠다고 봤다. 로그인 화면 하나, 세션 쿠키 하나로 화면 접근과 API 호출을 전부 같은 방식으로 맞추면 나중에 관리할 것도 줄어들 것 같았다.그런데 실제로 붙여보려니 걸리는 지점이 나왔다. ChatGPT 같은 프로그램은 브라우저가 아니다. ..

Kaniko에서 BuildKit으로 바꾸며 드러난 권한의 대가

빌더를 바꾸는 작업은 보통 "이미지가 그대로 빌드되고 푸시까지 되는지"만 확인하면 끝난다고 생각하기 쉽다. 나도 처음에는 그렇게 생각했다.그런데 이번에는 그렇지 않았다. 유지보수가 끊긴 빌더 하나를 다른 빌더로 옮기려고 했을 뿐인데, 작업을 진행하다 보니 클러스터에 어떤 권한까지 새로 허용해야 하는지를 다시 생각해야 했다.문제는 빌더가 아니라 전제였다내가 쓰던 파이프라인은 Kubernetes Job 안에서 컨테이너 이미지를 빌드해 레지스트리에 올리는 구조였고, 그 빌더로 Kaniko를 쓰고 있었다.Kaniko를 사용했던 이유는 단순했다. Docker daemon이나 privileged 컨테이너 없이 이미지를 빌드할 수 있다는 점이었다. 클러스터 안에서 이미지를 빌드해야 하는데 Docker-in-Docke..

AI 에이전트의 권한 거부를 모두 실패로 처리하면 안 되는 이유

AI 에이전트에게 문서 점검 작업을 맡겼다. 여러 프로젝트의 문서와 코드를 확인해 백로그 항목이 실제로 완료됐는지 판단하고, 근거가 있으면 상태를 갱신하는 작업이었다.작업은 거의 끝까지 진행됐다. 에이전트는 관련 저장소를 확인했고, 완료 근거가 부족한 항목은 그대로 대기로 유지했다. 대상 문서에는 확인 날짜와 근거도 정상적으로 갱신돼 있었다.그런데 최종 상태는 실패였다.원인은 작업 내용 자체가 아니었다. 에이전트가 참조 문서의 줄 수를 확인하려고 wc -l 명령을 한 번 실행하려 했고, 이 명령이 권한 정책에 의해 거부된 것이었다.권한 거부와 작업 실패는 같은 뜻이 아니다처음 정책은 단순했다.permission_denials가 하나라도 있으면 Task를 실패 처리한다.보안 관점에서는 자연스러운 규칙처럼 ..

운영 문서가 코드만큼 중요한 이유

코드가 잘 돌아가면 그것으로 충분하다고 생각하던 때가 있었다. 배포할지 말지, 지금 이 상태를 완료로 봐도 되는지, 다음에 뭘 해야 하는지는 어차피 내 머릿속에 다 있었으니까. 문제는 프로젝트가 하나가 아니게 되고, 같은 코드를 몇 주 뒤에 다시 열어보는 일이 반복되면서 시작됐다. 코드는 그대로 있는데, "지금 이걸 배포해도 되는가", "이 예외는 원래 있던 것인가 아니면 사고인가" 같은 질문에는 코드만 봐서 답이 나오지 않는 순간이 계속 생겼다.한 번은 인증 서비스의 설계 문서에 "이 서비스에는 공개 Ingress를 두지 않는다"고 명시적으로 적혀 있었다. 그런데 실제 배포 목록을 열어보니 관리자 화면으로 이어지는 Ingress가 이미 떠 있었다. 접근 IP를 제한해둔 상태라 위험한 구멍은 아니었다. ..

저장공간 부족은 1시간이었는데 흔적은 이틀 남았다 — 원인을 못 찾은 채 다음을 대비한 이야기

앞선 글에서 "주의 280건"의 정체는 종료된 Evicted Pod를 하루 종일 다시 센 숫자라는 것까지 확인했다. 남은 질문은 하나였다. 그 Pod들은 왜 쫓겨났고, 노드의 임시 저장공간은 왜 모자랐을까.결론부터 적으면 원인은 끝내 밝히지 못했다. 대신 다음에 같은 일이 생기면 원인이 남도록 관측을 하나 추가했다. 이 글은 왜 원인을 못 찾았는지, 그래서 무엇을 하고 무엇을 하지 않기로 했는지에 대한 기록이다.먼저 시간표를 맞춰 봤다노드 관측 이력과 Evicted Pod의 관측 시각을 나란히 놓고 보니 예상과 달랐다. 저장공간이 모자란 시간은 길지 않았다. 시각(KST) ..

일일 요약의 "주의 280건"은 장애가 아니었다 — 같은 종료 Pod를 하루 종일 다시 센 숫자

매일 아침 클러스터 점검 요약이 메신저로 온다. 어느 날 이런 줄이 와 있었다.정상 8 / 주의 280 / 위험 0 / 실패 0노드가 몇 대 안 되는 클러스터에서 주의 280이라니, 어디가 크게 잘못된 줄 알았다. 그런데 숫자만 있고 무엇이 문제인지는 어디에도 적혀 있지 않았다. 결국 이렇게 되물을 수밖에 없었다. "주의 280건이 뭐야?"확인해 보니 이 숫자는 노드 280개가 아니라 점검 회차를 센 것이었고, 그 대부분은 이미 끝난 Pod 몇 개가 하루 종일 반복해서 잡힌 결과였다.먼저 280이 무엇을 세는 숫자인지 확인했다요약은 하루 동안 쌓인 점검 기록을 상태별로 세어서 만든다. 점검이 5분마다 돌면 하루에 최대 288번이다. 그중 280번이 주의라면 거의 모든 회차가 주의였다는 뜻이다.여기서 두 ..