Kudu에 연결은 되지만 PutKudu 작업의 실제 인증 사용자에게 필요한 table 권한이 없다.
원본에서 권한 부족이 지적됐지만 어떤 권한을 부여했는지의 최종 기록은 없다. NiFi 1.x 문서의 PutKudu 기능을 NiFi 2.x에 동일하게 존재한다고 가정하지 않는다.
PutKudu가 사용하는 principal과 실제 Kudu table 이름을 확인해 필요한 INSERT·UPDATE 권한을 해당 보안 관리자에서 부여한다.
확인 수준: 추가 조사 해법 · 해당 케이스 적용 결과 미확인
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
- NiFi PutKudu → Configure → Properties에서 Kudu Masters·Table Name·Operation Type·Kerberos 관련 Controller Service를 확인한다. property 이름은 NiFi/CFM 버전에 따라 다르다.
- Kudu audit에서 거부된 사용자와 작업·table을 확인한다. NiFi OS 사용자가 nifi라는 이유로 인증 principal도 nifi라고 가정하지 않는다.
- keytab 방식이면 실제 NiFi 사용자에게 읽기 권한이 있는지 확인하고 별도 ticket cache에서 인증을 검증한다.
klist -ket '<nifi-keytab>'
KRB5CCNAME='FILE:<private-cache-path>' kinit -kt '<nifi-keytab>' '<nifi-principal@REALM>'
- 현재 Ranger 기반이면 Ranger Admin → Kudu 서비스 → 해당 table 정책에서 그 사용자·그룹에 필요한 작업만 부여한다. UPSERT는 삽입/수정 양쪽을 고려한다. 구버전 Sentry 기반이면 해당 배포의 Sentry 권한 경로를 사용한다.
- policy 전파를 확인한 뒤 Controller Service/processor를 지원되는 순서로 다시 활성화하고 작은 batch를 시험한다. Kudu의 RPC authentication·authorization을 끄거나 trusted user로 전체 권한을 주는 방식으로 우회하지 않는다.
동일 principal의 실제 PutKudu 작업이 성공하고 허용하지 않은 table 접근은 여전히 거부되는지 확인한다.