N° 01 — 목록
'분류 전체보기' (197)
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 03. fine-grained kubelet API authorization
Pod 목록을 읽으려면 exec 권한이 필요했다 — fine-grained kubelet API authorizationPrometheus가 노드의 Pod 목록을 수집하려 한다. 노드에 들어가 kubectl이 보는 것과 비슷한 정보를 얻으려면, kubelet이 10250 포트에 연 HTTPS API를 호출해야 한다. 그런데 1.32 이전의 kubelet에서 /pods를 읽으려면 RBAC상 nodes/proxy 권한이 필요했다. 문제는 이 nodes/proxy가 /pods(읽기)뿐 아니라 /exec/...(컨테이너 안에서 임의 명령 실행)를 인가하는 같은 권한이라는 점이다. 모니터링 에이전트가 Pod 개수를 세려다 노드 전체에 셸을 띄울 수 있는 능력을 함께 받은 셈이다.이 글은 kubelet API의 읽..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 02. authentication
"누구인가"를 증명하는 세 가지 방법 — Kubernetes 인증의 지형한 클러스터에 세 종류의 접속자가 있었다: 운영자(사람), CI/CD 파이프라인(자동화), 그리고 Pod 안의 앱. 셋 다 apiserver에 접근하지만 증명 방식이 달랐다 — 운영자는 회사 SSO(OIDC), CI는 서비스 계정 토큰, 앱은 마운트된 토큰. Kubernetes는 이 셋을 다른 방식으로 식별한다. "인증"이 하나가 아니라는 것을 모르면, 접속이 안 되는 이유를 엉뚱한 곳에서 찾는다.이 글이 푸는 것은: Kubernetes가 "누구인가"를 증명받는 여러 방식(X.509, OIDC, Service Account token)과 그 차이다. 특히 왜 세 방식이 다른가 — 접속자의 성격(사람/자동화/시스템)이 방식을 결정한다는..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 01. rbac
"누가 무엇을 할 수 있는가" — RBAC가 결정하는 권한의 단위한 클러스터에서 서비스 계정 하나가 모든 namespace의 Secret을 읽을 수 있었다. 개발자가 편하려고 ClusterAdmin을 줬기 때문이다. 그 서비스 계정이 탈취됐을 때, 공격자는 클러스터 전체의 비밀을 한 번에 들냈다. 이 사고의 원인은 RBAC의 오용이었다 — "편의를 위해 최대 권한"이 곧 "침해 시 최대 피해"가 된다.이 글이 푸는 것은: Kubernetes RBAC(Role-Based Access Control)이 "누가 무엇을 할 수 있는가"를 어떻게 결정하고, 최소 권한 원칙을 어떻게 실천하는가다. 03-k8s-security 영역의 출발점이자, 보안의 첫 번째 축이다.권한 제어의 세 축 — 누가, 무엇을, 어디서"..
-
Software Architecture/PrinciplesPrinciples - 08. 복잡성의 원천
흙은 없앨 수 없지만 잡초는 뽑을 수 있다 — 복잡성의 원천정원을 가꾼다고 하자. 흙이 있다 — 식물이 자라려면 흙이 필요하고, 흙의 종류·배수성·영양분이 복잡하다. 이건 정원의 본질이다, 없앨 수 없다. 하지만 잡초도 있다 — 우리가 심지 않았는데 자라난 것, 영양분을 빼앗고 정원을 어지럽힌다. 이건 뽑을 수 있다. "정원이 복잡하다"고만 말하면 흙과 잡초를 구분 못 한다 — 무엇이 본질이고 무엇이 우리가 만든 것인가를 가려야 한다.소프트웨어 복잡성도 두 종류다. Fred Brooks는 (1986)에서 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)을 나눴다. 본질적 복잡성은 문제 자체에서 온다 — 결제 도메인의 복잡한 규칙, 동시성 요구,..
-
Software Architecture/PrinciplesPrinciples - 07. 오류 처리 전략
배송 실패와 화물 사고는 다르다 — 오류 처리 전략택배를 보낸다고 하자. 수취인이 부재중이라 배송이 실패했다 — 이건 정상 흐름의 일부다. 내일 다시 배달하면 된다(복구 가능). 하지만 트럭이 사고를 내어 화물이 전소했다 — 이건 정상 흐름이 아니다. 운송 자체가 중단되고, 보상 청구라는 전혀 다른 경로로 넘어간다(복원 불가능).소프트웨어 오류도 이 두 종류로 나뉜다. 복구 가능한 오류(입력 검증 실패, 리소스 부족)는 정상 흐름의 일부로 다뤄야 하고, 복원 불가능한 오류(디스크 고장, 메모리 부족)는 흐름을 중단시키고 상위로 알려야 한다. 이 둘을 구분하지 않고 모두 예외로 던지면, 호출자가 매번 try-catch를 쳐야 하고 정상 흐름이 예외 처리에 묻힌다.예외 vs 결과 값 — 두 접근예외(exce..
-
Software Architecture/PrinciplesPrinciples - 06. 계약 설계와 API
메뉴판은 계약서다 — 계약 설계와 API식당에서 메뉴판을 본다. "된장찌개 8,000원"이라고 적혀 있다. 이 한 줄이 계약이다 — 8,000원을 내면(사전 조건) 된장찌개를 받는다(사후 조건). 주방에서 어떤 냄비를 쓰는지, 몇 분 끓이는지는 모른다. 메뉴판이 약속한 것만 지켜지면 된다. 메뉴판이 바뀌면(가격 인상, 메뉴 삭제) 손님이 혼란스럽다 — 계약이 변경된 것이다.소프트웨어의 API도 같다. 메서드 시그니처가 메뉴판이고, 호출 규칙이 계약이다. Bertrand Meyer는 에서 이를 계약에 의한 설계(Design by Contract)로 정식화했다 — 사전 조건(precondition), 사후 조건(postcondition), 불변 조건(invariant) 세 가지로 계약을 명시한다.사전 조건과..