Keycloak - 8. 리버스 프록시 설정, 테스트

KeyCIoak - 모던 애플리케이션을 위한 ID 및 접근관리 | 에이콘출판(주) | 스티안 토르거센, 페드로 이고르 실바 지음, 최만균 옮김

서적을 참고하여 요약한 시리즈 글이다.

 

---

1. 리버스 프록시 설정

 

1.1 리버스 프록시 요구사항

리버스 프록시는 여러 Keycloak 인스턴스에 대한 단일 및 공용 접근 포인트를 제공하고 정책 집합을 사용하여 부하 분산을 수행한다. 해당 인스턴스들은 보통 프라이빗 네트워크에 위치하기 때문에 프록시를 통해서만 접근할 수 있다.

 

 Keycloak은 자유롭게 리버스 프록시 적용이 가능하다. 아파치 HTTP 서버, Nginx, F5 및 HAProxy 등을 사용할 수 있다. 리버스 프록시를 사용하기 위한 기본적인 요구사항들은 다음과 같다.

• TLS 터미네이션 및 재암호화
• 부하 분산
• 세션 어피니티
• 헤더 전송

 

1.2 노드 부하 분산

Keycloak에서는 부하 분산을 위해 특별히 설정이 필요하지 않다. 하지만 고려해야하는 내용은 다음과 같다.

• 백엔드 노드 개수는 예상 로드, 가용성 및 시스템 대체 작동 시나리오를 고려해야한다.
• 응답 시간 및 처리량 측면에서 원하는 목표를 달성할 수 있는 적절한 알고리즘을 선택해야한다.

 

*로드 밸런서 관련 용어

• NAT(Network AddressTranslation): 사설 IP -> 공인 IP 주소로 변경해주는 역할
• DSR(Dynamic Source Routing protocol): 클라이언트의 요청이 로드밸런서를 타고와서, 서버에서 다시 응답을 할 때는 로드밸런서를 거치지 않고 클라이언트로 바로 전달되는 방식

 

 

1.3 클라이언트 정보 전송

 

리버스 프록시가 앞단에서 실행되는 경우, Keycloak은 요청을 생성한 클라이언트와 직접 통신하지 않고 리버스 프록시와 통신한다. 리버스 프록시가 요청을 해온 클라이언트의 정보를 알려주기 위해서 Keycloak이 필요로 하는 헤더를 전달해줘야한다. 주요 헤더는 다음과 같다.

• X-Forwarded-For: 요청을 전송한 클라이언트의 주소를 표시
• X-Forwarded-Proto: 클라이언트가 프록시와 통신하기 위해 사용하는 프로토콜을 표시
• Host: 프록시의 호스트 및 포트 번호를 표시

 

1.4 세션 어피니티(Sticky Session)

 

특정 클라이언트의 요청을 여러 노드 중 하나의 동일한 백엔드 노드를 사용해서만 처리하는 방식이다. 인증 코드 흐름을 사용하는 사용자 에이전트를 통해서 사용자를 인증하는 경우와 클라이언트가 Keycloak과 여러 번의 통신이 필요한 흐름을 사용하는 경우에 유용하다.

 

이번에도 역시 책의 내용이 최신 버전의 내용과 달라서, 공식 문서의 Sticky Session 부분을 잠시 공부하고자 한다.

https://wjw465150.gitbooks.io/keycloak-documentation/content/server_installation/topics/clustering/sticky-sessions.html

 

만약 인증 및 유저 세션이 node1에서 열려있고, 그에 해당하는 정보가 변경되어 cache에 저장되었다면 다른 owner( ex. node2)는 이에 대한 정보에 접근하기 위해서 node1에 요청을 보내야한다. 이런 불필요한 통신을 줄이기 위해서 node1에서 처리한 정보를 node1에서 바로 조회할 수 있도록 하는 것이 Sticky session이다.

 

Sticky Session은 클라이언트 -> 리버스 프록시 -> Keycloak으로 요청이 온 뒤, 특정 node1에서 authentication session을 만들면서 생성하는 random session ID를 기반으로 한다. 이렇게 생성된 session ID 값을 infinispan에 저장할 때 ID값을 hash한 값을 distributed cache들에 할당한다. 그 다음, Keycloak은 AUTH_SESSION_ID라는 쿠키를 만들고 <session_id>.<owner-node-id> 값으로 저장하여 활용하는 방식이다.

 

설정은 로드 밸런서 쪽에서 하면 된다고 한다. 여기서는 원리만 적당히 이해하고, 실제 구현이 필요할 때 학습하는게 학습효과가 좋을 것 같다!

 

1.5 HA Proxy 개념 및 설정 🎃

 

HA Proxy는 리버스 프록시를 구현할 수 있는 소프트웨어 중 하나이다. 하드웨어 스위치의 L4, L7 레이어에서 제공하는 스위치의 기능을 소프트웨어로 대신한다.

 

개념에 관한 내용은 아래 글을 참조해도 좋을 것 같다.

HA Proxy란?

 

 

그리고 HA Proxy 실습 관련해서는 따로 글을 작성했다. Docker Container를 통해서 하다보니 약간의 문제가 있어서 다음 글에 정리해두었다.

📝

Docker network: haproxy Layer4 connection problem, info: "Connect

 

 

2. Keycloak 환경 테스트

 

2.1 부하 분산 및 시스템 대체 작동 테스트

위 HA Proxy 실습 글 대로 container들을 실행했다면 아래처럼 3개의 컨테이너가 떠있는 상태이다.

 

이 상태에서 브라우저에서 https://localhost로 접속해보면 haproxy가 요청을 전달하여 kc1의 Sessions - lbTot 값이 1 증가하는 것을 확인할 수 있다.

 

그리고 token 요청의 Header - Cookie 정보를 보면 KC_ROUTE = kc1로 되어있어, kc1 인스턴스에 요청이 갔음을 확인할 수 있다.

 

이 상태에서 kc1에 해당하는 인스턴스를 종료해본다. 그리고 브라우저 페이지에서 새로 고침을 누른 뒤 token의 KC_ROUTE 값을 확인해본다. 그럼 아래처럼 kc2로 대체 작동이 된 것을 볼 수 있다.

 

 

Keycloak은 데이터가 인스턴스 간에 복제되도록 하며, 리버스 프록시는 요청을 자동으로 다른 노드에 전송한다.

 

 

2.2 프론트엔드 및 백엔드 URLs 테스트

 

OpenID Discovery 문서 및 Keycloak이 엔드포인트를 노출하는 방법에 대해 알아본다. 앞선 글들에서 다룬대로 hostname 값을 my.keycloak.org로 줬으므로 OpenID Discovery 문서 주소는 아래와 같다.

 

https://my.keycloak.org/realms/master/.well-known/openid-configuration

 

접속하면 아래처럼 keycloak이 제공하는 엔드포인트들을 볼 수 있다.