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)은 신원 위임자이자 리소스 제어자로 동작하게 하는 것이다. 이를 통해 다음과 같은 장점..

이전에는 Device Code 방식으로만 구성했기 때문에, 이번에는 표준 방식인 authorization_code(Standard flow) 방식으로 구성해본다. 1. 흐름도2. Auth Code 전용 kubeconfig 파일에 클러스터 정보 등록# clusterkubectl config --kubeconfig ~/.kube/config.auth-code-users set-cluster nks-cluster \ --server= \ --certificate-authority=~/.kube/nhn-ca.crt \ --embed-certs=true3. OIDC 사용자 등록# userkubectl config --kubeconfig ~/.kube/config.auth-code-users set-crede..

개발을 한다면 로깅 구성은 필수다. 서비스의 장애 원인 파악, 운영 중 문제 대응, 성능 모니터링까지 모두 로그를 기반으로 이루어진다.최근 auth-service를 구성하면서, 애플리케이션 로그를 위해 Volume 관련 설정을 추가했는데, 이 과정에서 Kubernetes 환경에서의 로깅 방식이 어떻게 동작하는지 궁금해졌다. 이번 글에서는 Kubernetes 환경에서의 로깅 구성 방식을 정리해본다.크게 파일 로깅과 STDOUT 로깅으로 나눠 살펴보자.1. 파일 로깅디스크에 기록: 애플리케이션이 파일로 직접 씀(/app/logs/app.log)롤링/보관 정책 가능: 사이즈/일자 기준 롤링, 보관 개수 제한 등 정밀 제어가 쉬움Pod 단위 격리: Pod마다 독립된 파일 Pod가 사라지면 파일도 같이 사라질 수..

지난 포스팅에서 Circuit Breaker의 개념과 흐름에 대해 알아보았다.이번에는 실제로 적용해보자. Feign Client 기반 Keycloak API 호출에 Circuit Breaker 적용장애 시 fallback 응답1. application.yaml 파일 설정 추가기존의 application.yaml 파일에 Resilience4j 기반 Circuit Breaker 설정 추가설정슬라이딩 윈도우: 10개최소 호출 수: 5개대기 시간 (open → half-open): 5초HALF_OPEN 상태에서 최대 3회 테스트 호출 허용spring: application: name: auth-service cloud: openfeign: circuitbreaker: en..

Circuit Breaker란?외부 시스템 호출 시 일정 비율 이상 실패가 발생하면, 해당 호출을 일시적으로 차단하여 시스템 전체 장애 확산을 방지하고 fallback 로직을 실행하는 보호 패턴흐름도1. 정상 흐름① 클라이언트가 로그인 요청② Feign Client (UserQueryClient) 호출③ Circuit Breaker 상태: CLOSED (실패율 ④ Keycloak 정상 응답 → JWT Access Token 반환이 경우는 Keycloak 서버가 정상 작동 중이며, Circuit Breaker가 요청을 그대로 전달Keycloak에서 토큰 발급 성공 → 클라이언트에 정상 응답 반환 (HTTP 200 OK)2. 장애 흐름 (Fallback 적용)⑤ Keycloak 장애 발생 → 실패 누적⑥ C..

1. 데모 네임스페이스kubectl create namespace demo-playground2. 네임스페이스만 권한 부여play-rbac-namespace.yaml# /play/viewers → demo-playground에서 read-onlyapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: play-viewers-ro namespace: demo-playgroundroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: viewsubjects:- kind: Group name: /play/viewers apiGroup: rbac.authoriz..

1. 클라이언트 설정realm: test-realmclient id: kubernetesClient authentication=OFFStandard Flow = ONOAuth 2.0 Device Authorization Grant = ON (디바이스 코드 로그인)Valid Redirect URIs: http://localhost/*Web Origins: (또는 http://localhost/)2. 그룹 클레임 매퍼Mapper Type: Group MembershipToken Claim Name: groupsFull group path: ONAdd to ID token: ON / Access token: ON / userinfo: ON3. 그룹그룹: /devops/admin, /play/editors, ..