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..

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, ..

흐름도상세 설명1. 사용자 → kubectl사용자가 kubectl 명령어를 통해 Kubernetes 클러스터 접속 시도oidc-login 플러그인을 이용하여 OIDC 설정(Issuer, ClientID, Secret, Groups)을 자동 매핑캐시된 인증 정보(~/.kube/cache/oidc-login)가 있으면 재인증 없이 사용 가능2. kubectl → Keycloakkubectl oidc-login 실행 시 Keycloak Authorization Server로 인증 요청OAuth 2.0 Device Authorization Grant 방식 사용브라우저 없이도 CLI 환경에서 안전하게 로그인 가능3. Device AuthorizationKeycloak이 Device Code, User Code, ..

Keycloak에서 발급받은 토큰을 기반으로 Kubernetes 클러스터 내 리소스에 접근할 수 있는 RBAC을 연동해보자. 1. namespace 생성Keycloak 리소스를 전용 네임스페이스에 모아 관리Context를 설정해 매번 -n keycloak 옵션 없이 명령 실행kubectl create namespace keycloakkubectl config set-context --current --namespace=keycloak2. cluster-issuer.yamlClusterIssuer는 cert-manager가 인증서를 발급할 때 참조하는 설정ACME 프로토콜을 사용해 Let’s Encrypt에서 인증서 자동 발급http01 방식 → Ingress를 통해 인증 검증cert-manager가..

개요Ubuntu 환경에서 Spring Boot 애플리케이션을 실행하고, Docker로 Keycloak 서버를 띄운 후, Nginx를 통해 HTTPS를 처리하는 구조로 배포Spring Boot 애플리케이션: Ubuntu 서버에서 실행 중이며, application.yaml 파일을 통해 환경별 설정 관리Keycloak: Docker를 이용하여 Keycloak 서버를 실행Nginx: 리버스 프록시 역할을 하며, HTTPS 요청에서 SSL을 처리하고, Spring Boot 애플리케이션과 Keycloak API 서버로 요청을 전달 1. Spring BootPort: 9000Context Path: /auth-serviceSwagger UI: /swagger-ui.html 경로에서 Swagger UI를 통해 ..