Cloudera Manager 가 관리하는 CFM NiFi 에서 인가를 파일 기반 정책 대신 Apache Ranger 로 옮기는 절차와, Ranger 로 어디까지 세밀하게 제어할 수 있는지를 정리한다. "특정 사용자에게 특정 프로세서의 설정만 읽게 한다" 수준까지 가능하다.
Cloudera 공식 보안 문서는 NiFi 가 어떤 형태의 사용자 인증이든 지원하려면 TLS/SSL 이 먼저 켜져 있어야 한다고 못박는다. 비보안 클러스터에서 LDAP 만 먼저 붙이는 경로는 없다. 따라서 순서는 TLS → 인증(LDAP) → 인가(Ranger) 다.
| 항목 | Auto-TLS | 수동 TLS |
|---|---|---|
| 인증서 발급 | CM 내부 CA 가 생성 · 배포 | 관리자가 keystore · truststore 를 미리 준비 |
| 신규 노드 추가 | 자동 배포 | 수동 배포 |
| 적용 위치 | CM → Administration → Security → Enable Auto-TLS | CM → NiFi → Configuration 에서 ssl 검색 후 입력 |
| 공통 제약 | 노드 인증서의 CN · SAN 이 노드 FQDN 과 정확히 일치해야 한다. 와일드카드 인증서는 쓰지 않는다 | 같음 |
CM → NiFi(또는 NiFi Registry) → Configuration 에서 다음처럼 둔다. authorizers.xml 을 직접 고치지 않는다 — CM 이 재배포 때 덮어쓴다. 구성 요소별 역할은 CFM NiFi 의 LDAP UserGroupProvider 와 authorizers 설정 에 있다.
| 구성 항목 | 값 |
|---|---|
| Enable File User Group Provider | 해제 |
| Enable Composite Configurable User Group Provider | 해제 |
| Enable Composite User Group Provider | 선택 |
| Composite UGP Provider 1 | ldap-user-group-provider |
| Composite UGP Provider 2 | cm-user-group-provider (노드 identity 를 자동으로 포함한다) |
| LDAP Enabled | 선택 |
| Ranger Authorizer — User Group Provider | composite-user-group-provider |
LDAP bind 비밀번호는 CM 의 비밀 항목으로 넣고 운영 문서에는 ${LDAP_BIND_PASSWORD} 처럼 적는다.
사전에 Ranger Admin 과 감사용 Solr 가 동작 중이어야 하고, Ranger 에 nifi · nifiregistry 그룹을 미리 만들어 둬야 한다.
| CM 구성 키 | 값 |
|---|---|
| RANGER 서비스 의존성 | 활성화 |
ranger.plugin.nifi.service.name |
Ranger Service Manager 에서 만든 NiFi 서비스 이름과 일치 |
ranger.plugin.nifi.policy.cache.dir |
/var/lib/nifi/policy-cache — /tmp 를 쓰지 않는다 |
NiFi Registry 는 같은 구조의 ranger.plugin.nifi-registry.* 로 따로 설정한다.
CFM 고유 절차다. 이 단계를 건너뛰면 Ranger 쪽에 사전 정의 정책이 생기지 않는다.
/proxy 정책 — 빠뜨리면 클러스터가 마비된다NiFi 노드끼리 요청을 프록시하므로, 노드 신원에 /proxy 권한이 없으면 UI 조회부터 큐 조작까지 전부 실패한다.
| 리소스 | 사용자 · 그룹 | 권한 |
|---|---|---|
/proxy |
nifi 그룹 (또는 각 노드 DN) |
Read + Write |
NiFi Registry 쪽 /proxy 에는 nifiregistry 와, Registry 로 접속하는 NiFi 노드까지 넣는다.
| 리소스 | 의미 |
|---|---|
/flow |
NiFi UI 접근. 모든 사용자에게 최소 Read 가 필요하다 |
/controller |
컨트롤러 설정 · 보고 태스크 · 컨트롤러 서비스 |
/proxy |
노드 간 프록시 요청 |
/tenants |
사용자 · 그룹 조회 |
/resources |
Ranger 가 NiFi 리소스 목록을 수집할 때 쓴다 |
/restricted-components |
ExecuteScript 처럼 위험한 컴포넌트 사용 제한 |
/counters · /provenance · /parameter-contexts · /system |
각각 카운터, 데이터 유래, 파라미터 컨텍스트, 시스템 진단 |
| 리소스 | 제어 대상 |
|---|---|
/process-groups/<PG_UUID> |
특정 프로세스 그룹의 설정 조회 · 수정 |
/processors/<UUID> |
특정 프로세서의 설정 조회 · 수정 |
/controller-services/<UUID> |
컨트롤러 서비스 설정 |
/input-ports/<UUID> · /output-ports/<UUID> · /funnels/<UUID> · /labels/<UUID> · /remote-process-groups/<UUID> |
각 컴포넌트 설정 |
/data/process-groups/<PG_UUID> |
해당 그룹의 FlowFile 내용 조회, 큐 목록 · 비우기 |
Read 와 Write 를 따로 준다. 명시적 정책이 없으면 상위 프로세스 그룹의 정책을 상속하므로, 상위에만 걸고 하위에서 예외를 재정의하는 방식이 관리하기 쉽다.
/proxy · /actuator · /swagger · /tenants · /buckets 가 사전 정의되고, /buckets/<BUCKET_UUID> 로 버킷 단위 Read · Write · Delete 를 나눌 수 있다. 팀 A 만 자기 버킷에 플로우 버전을 저장하고 팀 B 는 읽기만 하는 구성이 여기서 나온다.
| 요구 | 정책 |
|---|---|
| USER_A 에게 특정 프로세서 설정 읽기 허용 | /processors/<UUID> · USER_A · Read |
| USER_B 가 프로세스 그룹 A 를 못 보게 | /process-groups/<PG_A_UUID> 정책에서 USER_B 제외. 상속으로 새어 들어오지 않도록 상위 그룹 정책에서도 제외한다 |
| 큐 내용 조회 · 비우기 허용 | /data/process-groups/<PG_UUID> Read+Write 와 동시에 모든 NiFi 노드(nifi 그룹)에 /data/* Read+Write 가 필요하다. 노드 간 분산 요청이기 때문이다 |
| 팀별 Registry 버킷 격리 | /buckets/<BUCKET_UUID> 단위 정책 |
| ExecuteScript 계열 제한 | /restricted-components 하위 정책으로 필요한 카테고리만 허용 |
cm-user-group-provider 기준으로 CN=<hostname> 형태다. LDAP 사용자 DN 과 표기 형식이 섞이면 식별자 매핑에서 어긋난다./resources 접근이 가능해야 한다. 정지 상태면 UUID 를 직접 입력해야 한다.