Cloudera Manager 에서 Kudu 서비스의 Ranger 연동을 켜자 마스터가 기동하지 못하고 반복 재시작한다. stdout.log 에는 몇 초 간격으로 같은 내용이 반복되고 마지막에 minidump 만 남는다.
KUDU_HOME: /opt/cloudera/parcels/CDH-.../lib/kudu
CMD: master
Found master(s) on master01,master02,util01
Kerberos not enabled, won't connect to Ranger
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Wrote minidump to /var/log/kudu/minidumps/kudu-master/<id>.dmp
Kudu 의 Ranger 인가는 "요청 주체가 누구인가" 가 신뢰할 수 있어야 성립한다. Kerberos 가 없으면 Kudu 는 클라이언트가 자기 신고한 OS 사용자 이름을 그대로 쓰므로, 누구나 원하는 이름을 댈 수 있다. 그 위에 정책을 얹어도 통제가 되지 않는다. 그래서 기동 스크립트가 Kerberos not enabled, won't connect to Ranger 를 찍고 연동 자체를 건너뛴다.
결론부터 말하면 Kerberos 없이 Kudu 에 Ranger 를 제대로 붙일 방법은 없다. 아래는 그럼에도 시도했을 때 무슨 일이 일어나는지와, 대신 쓸 수 있는 통제 수단의 기록이다.
같은 Kudu 버전이라도 CDP 배포판의 기동 스크립트가 다르다. 관찰된 차이는 다음과 같다.
| 배포판 | 동작 |
|---|---|
| CDP 7.1.9 | Kerberos 가 꺼져 있으면 Ranger 연결을 시도하지 않고 넘어간다 |
| CDP 7.3.1 | Ranger 에 정책 다운로드 요청을 보내고 401 Unauthorized 를 받는다 |
7.3.1 에서 401 을 받으면 플러그인 초기화가 실패하고 마스터가 기동하지 못한다. 7.1.9 에서는 같은 설정이 "조용히 무시" 되므로, 두 클러스터를 같은 설정으로 맞췄다고 생각하는 순간 한쪽만 죽는다.
Ranger Admin 쪽에서 정책 다운로드를 허용하는 사용자 목록에 Kudu 마스터를 실행하는 OS 계정이 들어 있어야 한다. 서비스 정의의 설정 항목이다.
policy.download.auth.users = kudu
여기 적는 이름은 Kudu 마스터 프로세스의 실행 계정이다. Cloudera Manager 배포에서는 kudu 인 것이 보통이지만 확인한다.
ps -ef | grep '[k]udu-master' | awk '{print $1}'
서비스 이름도 정확히 일치해야 한다. Kudu 쪽 설정과 Ranger Admin 에 등록된 이름이 한 글자라도 다르면 정책 조회가 401 또는 404 가 된다.
grep -n 'service.name' /var/run/cloudera-scm-agent/process/*-kudu-KUDU_MASTER/ranger-kudu-security.xml
Kudu 쪽 플래그도 함께 본다.
grep -nE 'ranger_|trusted_user_acl|superuser_acl' \
/var/run/cloudera-scm-agent/process/*-kudu-KUDU_MASTER/gflagfile
| 플래그 | 역할 |
|---|---|
--ranger_config_path · --ranger_jar_path · --ranger_java_path |
플러그인 구동에 필요한 경로 |
--ranger_service_name |
Ranger 에 등록된 서비스 이름 |
--trusted_user_acl |
인가 검사를 건너뛰는 신뢰 사용자 |
--superuser_acl |
관리 작업이 가능한 사용자 |
위 항목을 모두 맞춘 뒤에도 CDP 7.3.1 에서는 401 이 계속됐고, 기록은 여기서 끝난다. Ranger Admin 의 인증을 통째로 끄는 설정(ranger.policy.rest.disableAuth)이 해법으로 제시됐으나 적용하지 않았고, 이 속성이 해당 버전에서 실제로 존재하며 의도대로 동작하는지도 확인하지 못했다 (확인 필요). 운영 클러스터에 적용할 만한 방법도 아니다 — Ranger Admin 전체의 REST 인증을 없애는 것이라 Kudu 하나 때문에 다른 모든 플러그인의 통제를 푸는 셈이 된다.
다음에 이어서 볼 것은 Ranger Admin 쪽 접근 로그에서 401 을 낸 요청의 주체와 경로를 확인하는 것이다. Kudu 가 어떤 사용자 이름으로 요청했는지가 로그에 남으므로, 그 이름과 policy.download.auth.users 를 대조하면 갈린다.
grep -i 'kudu' /var/log/ranger/admin/ranger_admin_access.log | tail -50
Kerberos 를 켤 수 없는 클러스터에서 Kudu 접근을 줄이는 현실적인 수단은 다음 정도다. 어느 것도 인가 체계의 대체는 아니다.
Kudu 자체 ACL 로 관리 작업 주체를 제한한다. 이름을 자기 신고하는 구조이므로 오조작 방지 이상은 되지 않는다.
--superuser_acl=kudu,impala
--user_acl=*
Impala 를 유일한 접근 경로로 두고 Kudu 포트(마스터 7051, tablet server 7050)를 네트워크에서 Impala 노드에만 열어 둔다. Impala 쪽에는 Ranger 인가와 LDAP 인증이 걸리므로 실질적인 통제가 여기서 이루어진다. Kudu 직접 접근을 막는 것이 핵심이다.
그리고 통제가 필요한 환경이라면 결국 Kerberos 를 켜는 것이 맞다. Ranger 연동뿐 아니라 Kudu 의 인증 자체가 그것을 전제로 설계돼 있다.