Hue 에서 자주 나오는 두 가지 오류를 다룬다. 하나는 파일브라우저에서 HDFS 경로를 열 때 나오는 HttpFS 401 이고, 다른 하나는 로그인 후 동작에서 나오는 CSRF 403 이다. 둘 다 권한 문제로 오해하기 쉽지만 각각 인증 채널과 쿠키·프록시 문제다.
파일브라우저에서 다음과 같은 오류가 나오는 경우다.
Cannot access: /user/<uid>.
401 Client Error: Unauthorized access for url:
https://<httpfs-host>:14000/webhdfs/v1/user/<uid>?user.name=hive&doas=<uid>&op=GETFILESTATUS
401 이지 403 이 아니라는 점이 핵심이다. HttpFS(포트 14000)의 인증 단계에서 막힌 것이고 퍼미션 문제가 아니다. Hue 가 hive 계정으로 붙은 뒤 doAs 로 대리 실행을 시도하는 구조인데, 그 앞단 인증 필터에서 거부됐다. 프록시유저 거부였다면 보통 403 이 반환된다.
가장 먼저 가를 것은 특정 사용자만인지 전체 사용자인지다.
특정 사용자만 실패하면 그 계정이 FreeIPA·LDAP 동기화가 안 됐거나 홈디렉터리 프로비저닝이 안 된 경우가 많다. 신규 계정에서 자주 나타난다.
hdfs dfs -ls /user/ | grep <uid>
HttpFS 의 프록시유저 설정도 확인 대상이지만 이 경우는 보통 403 으로 나므로 후순위다 — httpfs.proxyuser.<주체>.hosts 와 httpfs.proxyuser.<주체>.groups 를 본다.
전체 사용자가 실패하면 Hue 와 HttpFS 사이의 인증 채널 자체가 끊긴 것이다. HttpFS 가 authentication.type=kerberos 인데 SPNEGO 핸드셰이크가 깨지면 모든 요청이 401 이 된다. 키탭 로테이션 후 재기동 누락, KDC 통신 장애, 인증 필터 초기화 실패가 흔한 원인이다.
Hue 를 거치지 않고 HttpFS 를 직접 호출해 원인을 격리한다.
kinit -kt <httpfs.keytab> <httpfs-principal>
curl -i --negotiate -u : \
"https://<httpfs-host>:14000/webhdfs/v1/user?op=LISTSTATUS"
여기서도 401 이면 HttpFS 나 KDC 문제이고, 200 인데 Hue 만 401 이면 Hue 서비스 계정·설정 문제다. 함께 볼 것은 HttpFS 역할 상태와 로그(/var/log/hadoop-httpfs/ 에서 GSSException · keytab · clock skew 검색), 그리고 시간 동기화다. Kerberos 는 5분만 틀어져도 인증이 깨진다.
timedatectl status
chronyc tracking
원래 잘 되다가 특정 시점부터 전체가 막혔다면 직전의 키탭 갱신·인증서 교체·KDC principal 변경·노드 재기동 이력을 확인한다.
로그인은 되는데 쿼리 실행이나 저장에서 CSRF 403 이 나는 경우다. 1차 진단은 시크릿 창에서 재현되는지 확인하는 것이다.
시크릿 창에서 정상이면 브라우저에 남은 오래된 세션·CSRF 쿠키가 원인이다. 해당 도메인의 쿠키만 삭제하고 재로그인하면 새 토큰이 발급되어 해결된다. 증상이 반복되면 쿠키를 차단하거나 주기적으로 삭제하는 확장 프로그램을 의심한다.
시크릿 창에서도 재현되면 서버나 프록시 설정 문제다. 리버스 프록시·로드밸런서 뒤에 Hue 를 두면 CSRF 가 자주 깨진다.
hue.ini 의 [desktop] secret_key 가 다르면 CSRF 검증이 실패한다. 모든 노드에 같은 값을 넣는다. 이 값은 로그나 코드에 노출되지 않게 관리한다.hue.ini 에 다음을 설정하고 프록시가 X-Forwarded-Proto: https 를 넘기는지 확인한다.[desktop]
secure_proxy_ssl_header=true
Referer 나 Origin 헤더를 제거하면 Django 의 CSRF 검증이 실패한다. proxy_set_header 로 원본 Host·Origin·Referer 가 유지되는지 확인한다.