redcedar137 님의 블로그

이번 글에서는 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가 사라지면 파일도 같이 사라질 수..

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

먼저 Git 허브에 레포지토리 생성생성한 레포지토리를 클론gh-pages 브렌치 생성해당 경로에 index.html 파일 작성https://github.com/stefanprodan/helm-gh-pages

Kubernetes에서 네트워크를 이야기 하려면 먼저 Pod Network와 Service Network로 구분 Pod NetworkKubernetes에서 Pod Network는 Pod에 IP를 할당하고 Pod간 통신을 담당먼저 Pod A와 Pod B간에 통신에 대해서 생각 해보고 (같은 Node에 있는 pod간 통신)Pod A와 Pod C간의 통신을 생각(서로 다른 Node에 있는 Pod간 통신)이렇게 Pod에 IP를 부여하고 Pod간 통신을 담당하는 역할이 CNI(Container Network Interface)Kubernetes에는 기본적으로 Kubenet이라는 간단하고 기본적인 네트워크 플러그인을 제공해주지만기본적이고 간단한 기능만 제공을 해주고 위 그림에서 예시 두 번째처럼 서로 다른 N..