redcedar137 님의 블로그

이전에는 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. 이미지 빌드 및 푸시MSA 연동 과정에서 사용했던 auth-service 코드를 그대로 사용이미지를 생성해서 푸시하는 과정이므로 로컬에서 작업해도 무관Buildpacks 방식bootBuildImage가 제공하는 Cloud Native Buildpacks를 활용하여 이미지를 직접 생성JDK/JRE 버전 관리, 이미지 레이어화, 보안 패치 자동 반영Dockerfile처럼 세세한 커스터마이징 불가# Buildpacks 이미지 생성./gradlew bootBuildImage --imageName /auth-service:1.0.0# Docker Hub 푸시docker push /auth-service:1.0.0Dockerfile 방식직접 작성한 Dockerfile을 기반으로 이미지를 빌드이미지 레이어/구성..

1. 개요인증 서비스와 사용자 관리 기능 제공사용자 로그인, 회원가입, 패스워드 리셋, 로그아웃 등의 기능을 통해 인증 및 권한 관리 수행관리자 역할을 위한 사용자 생성 및 삭제 등의 관리 기능 제공 2. API 목록user-command-controllerPOST /users: 사용자 생성 APIPUT /users/reset-password: 사용자 패스워드 변경 APIDELETE /users: 사용자 탈퇴 APIPOST /users/logout: 사용자 로그아웃 APIuser-query-controllerPOST /users/login: 사용자 로그인 APIPOST /users/one-pass-login: Client Credentials 방식 로그인 API 3. 코드Feign Client..

들어가며지금까지는 Keycloak의 기본 설정과 토큰 발급 과정을 개별적으로 살펴봤다.하지만 실제 서비스 환경에서는 Keycloak이 하나의 독립된 인증 서버로 동작하며,각각의 MSA 서비스(Spring Boot 애플리케이션) 와 통신하면서 사용자 인증과 권한을 관리한다. 이번 글에서는 Keycloak을 실제 MSA 구조 안에 연결해보며,사용자 로그인 흐름과 관리자 작업 흐름이 어떻게 다르게 동작하는지 살펴본다.사용자는 password 방식을 통해 로그인 후 Access Token을 발급받아 서비스 API를 호출하고,관리자는 client_credentials 방식을 통해 Admin Token을 발급받아Keycloak의 Admin API를 통해 사용자 CRUD 등의 관리 작업을 수행한다. DevOps 관점..

Keycloak은 OAuth 2.0/OIDC 표준을 바탕으로 여러 가지 토큰 발급 방식을 지원한다.겉으로 보기엔 “토큰 받기”가 전부 같아 보이지만, 실제로는 사용자 개입 여부, 보안 수준, 대상 워크로드가 모두 다르다.이번 글에서는 client_credentials, password, authorization_code를 중심으로 언제 어떤 방식을 써야 하는지를 정리하고, authorization_code 방식에서는 실습 가능한 cURL + 간단한 Spring Boot/프론트 흐름까지 연결해본다. 1. client_credentials 방식클라이언트 자체가 인증 주체가 되는 방식일반 사용자 로그인 없이 서비스 간 통신(Backend to Backend)에서 주로 사용세션 생성되지 않음발급된 토큰은..