redcedar137 님의 블로그

앞에서 Keycloak Realm/Client, OIDC, 그룹/클레임 구성을 통해“JWT 한 장으로 Kubernetes apiserver까지 신뢰 체인”을 만들었다면,이제 그 토큰을 이용해서 실제 Kubernetes 리소스를 다루는 애플리케이션 레이어를 구성할 차례다.이 서비스의 목표는 간단하다. “사용자 브라우저에서 받아온 Bearer 토큰을 그대로 Kubernetes에 전달해서,백엔드는 그대로 프록시 역할만 하고, 실제 권한 판단은 전부 Kubernetes RBAC에 맡긴다.” 이를 위해 백엔드는 /api/k8s 하위에 얇은 REST API를 두고,내부에서는 Kubernetes Java Client(CoreV1Api)를 호출하도록 구성했다.구조는 크게 세 부분으로 나뉜다.Web 계층: K8sWebB..

이전 글에서는 전용 Ingress Controller를 구성하고 Helm Chart를 이용해 Keycloak을 Kubernetes 클러스터에 배포하는 과정까지 살펴보았다.이제 Keycloak이 안정적으로 외부에서 접근 가능한 환경이 마련되었으므로, 실제로 Kubernetes API 서버와 안전하게 연동할 수 있도록 OIDC 인증·인가 설정을 구성해야 한다. 이번 글에서는 다음 흐름을 중심으로 Keycloak 설정을 정리한다.어떤 클라이언트(Client) 설정이 토큰(OIDC ID Token)에 필요한 클레임을 포함시키는지Kubernetes RBAC(Role/RoleBinding)과 연동되기 위해 왜 groups/aud 같은 클레임이 필수인지Keycloak 그룹 구조를 어떻게 설계하고 매퍼를 어떤 방식으..

이번 글에서는 Helm Chart를 이용해 Keycloak을 Kubernetes 클러스터에 배포하는 과정을 다룬다. 현재 사용 중인 클러스터는 여러 서비스가 함께 공유하는 환경이며,이미 운영 중인 공용 Ingress Controller가 존재한다.문제는 이 Ingress Controller가 SNAT(Source NAT) 처리를 수행하고 있어,클라이언트의 퍼블릭 IP가 Pod까지 전달되지 않는다는 점이다. Keycloak은 로그인 이력, 세션 추적, 보안 로그 등에서 클라이언트 IP를 사용하기 때문에이 IP 정보가 모두 Ingress 노드의 IP로 치환되면 추적이 불가능해진다.하지만 공용 Ingress 설정은 다른 워크로드와 공유 중이라,이를 직접 수정하거나 SNAT 동작을 끄는 것이 불가능했다. ..

들어가며마이크로서비스 아키텍처(MSA) 환경에서모든 요청의 인증(Authentication)과 인가(Authorization)를 애플리케이션 레벨에서 처리한다면 서비스마다 인증 로직이 중복되고, 요청당 검증 오버헤드가 누적된다.이는 확장성과 비용 효율성을 모두 저해하는 구조다. 이번 시리즈에서는 이 문제를 해결하기 위해서비스 메시(Istio) 레벨에서 인증과 인가를 수행하고,애플리케이션(Spring Boot)은 검증이 완료된 신원을 위임받아Kubernetes 클러스터 리소스를 제어하는 역할만 수행하는 구조를 구축한다. 이 구조의 핵심은인증과 인가를 인프라 레벨(Istio) 로 끌어올려 애플리케이션(Spring Boot)은 신원 위임자이자 리소스 제어자로 동작하게 하는 것이다. 이를 통해 다음과 같은 장점..