Ranger Architecture

Apache Ranger의 분산형 아키텍처

 

Plugin 동작 구조

플러그인은 각 구성 요소의 프로세스 내 포함되는 경량 Java 프로그램입니다.

공식 문서에서는 응용 프로그램은 표준 플러그인 모델을 통해 Ranger와 통합된다고 나와있는데 뭔가 명확하지 않죠?

서비스 플러그인(ranger-hive-plugin , ranger-hdfs-plugin...혹은 여러분이 만드신 custom-plugin) 은 모두 RangerBasePlugin 이라는 클래스 상속받아 구현됩니다.

이를 공식 문서에서는 '표준 플러그인 모델을 통해 Ranger와 통합' 이라고 표현했네요.

 

플러그인의 기능 

권한 검증

플러그인은 서버에 정의된 권한 부여 정책을 이용하여 사용자 엑세스를 검증합니다.

사용자 요청이 구성 요소를 통해 들어오면 플러그인이 요청을 가로채 보안 정책에 대해 평가합니다.

 

위의 설명이 무슨말인지 감이 안 오신다면, 사용자가 어떤 리소스에 접근을 할 때 레인저 플러그인이 접근 허용 여부를 판단해준다고 이해하시면 될 것 같습니다.

Ranger 플러그인이 활성화되면 Ranger는 모든 액세스를 완전히 제어합니다.

정책 검증은 Ranger 의 몫입니다. 우리는 간단한 함수 호출로 사용자의 권한을 검증할 수 있습니다.

 

정책 폴링

사용자가 정책을 생성 혹은 업데이트하면 플러그인은 Ranger Admin Portal의 정책을 주기적으로 폴링 하고 이를 local cache file로 저장합니다.

따라서 정책 서버가 일시적으로 다운된 경우에도 작동 권한 검증이 가능합니다.

 

감사 로그 작성

플러그인은 사용자 요청에서 데이터를 수집, 별도의 스레드를 따라 이 데이터를 감사 서버로 전송하여 감사 로그를 남깁니다.

간단히 말해서 서비스에 접근한 유저와 접근 대상 리소스를 로그로 남긴다고 생각하시면 됩니다.

아래 이미지의 위의 노란 화살표를 봐주세요.

 

플러그인 통신 

플러그인과 Ranger 정책 서버(RPS) 는 양방향 통신을 제공합니다.

 

첫 번째는 Plugins to RPS 통신입니다.

이는 플러그인 작동에 필수적 요소로 Ranger 플러그인과 Ranger Policy Server 간의 통신을 이야기합니다.

플러그인은 정기적으로(30초) Ranger Policy Server를 호출하여 RAP(Ranger Administration Portal )에 새로운 정책이 정의되었는지 확인합니다.

 

두 번째는 RPS to components 통신입니다.

정책 정의 시 자동 완성 및 드롭 다운 목록을 제공하는데 RPS to components 가 작동하지 않는 경우 정책 정의 및 시행은 가능하지만 정책 정의 중 자동 완성이 불가능합니다.

 

* 무단전제 및 재배포금지