Integrações - Ranger

ChartVersion3.0.1TypeapplicationAppVersion2.7.0

CompatibilidadeKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Visão geral das integrações

O chart tdp-ranger pode usar um PostgreSQL externo (tdp-postgresql) como banco de metadados e de auditoria — consulte Configuração do Ranger.

O bloco rangerIntegrations automatiza uma parte específica do fluxo de integração: o cadastro de serviços e políticas no Ranger Admin.

Quando rangerIntegrations.configJob.enabled=true, o chart executa um job pós-instalação ou pós-atualização que aguarda o Ranger Admin responder, lê as integrações habilitadas, cadastra ou atualiza os serviços correspondentes no Ranger Admin e cria as políticas declaradas em defaultPolicies, quando configuradas.

Sem esse job, esse cadastro precisa ser feito manualmente na interface ou API do Ranger Admin.

Escopo da automação

Essa automação atua no lado do Ranger Admin.
A configuração do serviço integrado para consultar o Ranger, quando necessária, deve ser feita conforme a documentação específica do respectivo componente.
Habilitar rangerIntegrations.<SERVICE_KEY>.enabled=true não configura o componente de ponta a ponta.

Automação desabilitada por padrão

rangerIntegrations.configJob.enabled é false por padrão.
Para automatizar o cadastro no Ranger Admin, habilite esse parâmetro no seu arquivo de valores.

Padrão de configuração

O mesmo modelo de configuração pode aparecer em três escopos, dependendo de como o chart é usado no ambiente:

Escopo	Uso
rangerIntegrations.*	Consumido pelos recursos renderizados pelo tdp-ranger, incluindo job e ConfigMap de integração
tdp-ranger.rangerIntegrations.*	Repassado ao subchart do Apache Ranger
global.rangerIntegrations.*	Compartilhado com subcharts que consomem valores globais

Use o escopo que corresponde ao pacote implantado.
Quando o cadastro no Ranger Admin depender do job automático, garanta que rangerIntegrations.configJob.enabled=true.

Pré-requisitos

• Ranger Admin implantado e acessível pelo Service interno.
• Senha do usuário administrador configurada e disponível para o job de integrações.
• Serviço de destino implantado e acessível por rede.
• Nome do serviço no Ranger definido em serviceName.
• Credenciais e endpoints compatíveis com o tipo de serviço cadastrado no Ranger Admin.
• Configuração do componente integrado feita no próprio chart ou documentação do componente, quando ele precisar consultar o Ranger em tempo de execução.
• Políticas declaradas em defaultPolicies revisadas antes de aplicar em ambiente compartilhado.

Job de integrações

O job de integrações é executado após instalação ou atualização do release.
Ele aguarda o Ranger Admin responder, instala dependências Python no container do job e executa o script que cadastra serviços e políticas no Ranger Admin.

Parâmetros principais:

Parâmetro	Descrição
rangerIntegrations.configJob.enabled	Habilita o job automático
rangerIntegrations.configJob.image	Imagem usada pelo container de configuração
rangerIntegrations.configJob.imagePullPolicy	Política de pull da imagem
rangerIntegrations.configJob.rangerReadyTimeout	Tempo máximo de espera pelo Ranger Admin
rangerIntegrations.configJob.retryInterval	Intervalo entre tentativas

Exemplo:

rangerIntegrations:
  configJob:
    enabled: true
    rangerReadyTimeout: 600
    retryInterval: 10

Exemplos de integrações

As seções seguintes mostram exemplos de configuração aceitos por rangerIntegrations.
Elas não devem ser lidas como uma lista conceitual fixa de tudo que o Apache Ranger pode proteger.

Kafka

A configuração de Kafka registra um serviço do tipo Kafka no Ranger Admin.
Ela precisa dos endpoints de bootstrap, conexão com ZooKeeper quando exigida pelo plugin e protocolo de segurança.
Essa configuração demonstra o cadastro no Ranger Admin e a criação das políticas declaradas em defaultPolicies, quando existirem.
Ela não afirma que o chart do Kafka configure automaticamente o plugin do Ranger no broker.

rangerIntegrations:
  configJob:
    enabled: true
  kafka:
    enabled: true
    serviceName: "tdp_kafka"
    serviceDisplayName: "TDP Kafka Cluster"
    connection:
      bootstrapServers: "<KAFKA_BOOTSTRAP_SERVICE>.<NAMESPACE>.svc.cluster.local:9092"
      zookeeperConnect: "<ZOOKEEPER_SERVICE>.<NAMESPACE>.svc.cluster.local:2181"
      securityProtocol: "PLAINTEXT"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

Use defaultPolicies para criar políticas declaradas de tópicos, cluster, transactional ID e delegation token quando isso fizer parte do bootstrap do ambiente.
Revise grupos e usuários antes de aplicar políticas amplas como acesso total.

Para habilitação rápida via linha de comando:

helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
  -n <NAMESPACE> \
  --set rangerIntegrations.kafka.enabled=true \
  --set rangerIntegrations.kafka.connection.bootstrapServers=<KAFKA_BOOTSTRAP_SERVERS> \
  --set rangerIntegrations.kafka.connection.zookeeperConnect=<ZOOKEEPER_CONNECT>

Trino

A configuração de Trino registra no Ranger Admin um serviço com URL JDBC e driver do Trino.
Ela permite declarar políticas para catálogos, schemas, tabelas e colunas no Ranger Admin.
Esse cadastro não substitui a configuração do controle de acesso Ranger no chart do Trino; o Trino também precisa estar configurado para consultar o Ranger em tempo de execução.

rangerIntegrations:
  configJob:
    enabled: true
  trino:
    enabled: true
    serviceName: "tdp_trino"
    serviceDisplayName: "TDP Trino Cluster"
    connection:
      jdbcUrl: "jdbc:trino://<TRINO_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      jdbcDriverClassName: "io.trino.jdbc.TrinoDriver"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

As credenciais devem representar um usuário técnico capaz de validar a conexão do serviço cadastrado no Ranger.
As políticas devem refletir o modelo de dados do ambiente, evitando liberar catalog, schema e table como * sem revisão.

NiFi genérico

A configuração NiFi genérica registra um serviço NiFi no Ranger Admin.
Ela pode ser útil para cenários simples, mas não cobre todo o fluxo de produção em que o NiFi usa Ranger como authorizer principal.
Essa configuração demonstra o cadastro no Ranger Admin e a criação das políticas declaradas em defaultPolicies, quando existirem.
Ela não afirma que o chart do NiFi configure automaticamente o authorizer do Ranger.

rangerIntegrations:
  configJob:
    enabled: true
  nifi:
    enabled: true
    serviceName: "tdp_nifi"
    serviceDisplayName: "TDP NiFi Cluster"
    connection:
      nifiUrl: "http://<NIFI_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      internalUrl: "http://<NIFI_HEADLESS_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      authenticationType: "none"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

Use esse modo apenas quando ele corresponder ao modelo de segurança do NiFi implantado.
Para NiFi com autorização centralizada no Ranger, use o padrão com mTLS descrito abaixo.

Arquivo de overlay dedicado

Para integração do NiFi com o Ranger como authorizer, utilize o arquivo de overlay dedicado fornecido com o chart. Ele já alinha a definição do serviço com a documentação do plugin Apache Ranger para NiFi, apontando nifi.url para /nifi-api/resources e usando um hostname que esteja presente nos SANs dos certificados do NiFi.

Terminal input

helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
  -n <NAMESPACE> \
  -f values-nifi-ranger-authorizer.yaml

NiFi como authorizer via Ranger

Quando o NiFi usa Ranger como authorizer principal, o cadastro do serviço no Ranger Admin precisa ser compatível com o fluxo de mTLS entre Ranger e NiFi.
Nesse cenário, o Ranger acessa o endpoint /nifi-api/resources, cria usuários técnicos e cria as políticas declaradas em defaultPolicies para que o cluster NiFi consiga operar.
Esse fluxo exige também a configuração correspondente no chart do NiFi para que o NiFi consulte o Ranger como authorizer.

Antes da instalação, crie o Secret com a senha estável do JKS:

kubectl -n <NAMESPACE> create secret generic ranger-nifi-client-tls-password --from-literal=password='<KEYSTORE_PASSWORD>' --dry-run=client -o yaml | kubectl apply -f -

Para uma primeira instalação, também é possível criar o Secret em um comando direto:

kubectl -n <NAMESPACE> create secret generic ranger-nifi-client-tls-password --from-literal=password='<KEYSTORE_PASSWORD>'

Não rotacione essa senha casualmente.
Se ela mudar sem reemitir o Secret de certificado cliente, o Ranger pode falhar ao abrir keystore.jks e truststore.jks.

Configuração principal:

rangerIntegrations:
  configJob:
    enabled: true
  nifi:
    enabled: true
    serviceName: "tdp_nifi"
    serviceDisplayName: "TDP NiFi Cluster"
    technicalUsers:
      - "CN=ranger-nifi-client"
      - "CN=nifi-controller"
    tlsClientCertificate:
      autoGenerate:
        enabled: true
        secretName: "ranger-nifi-client-tls"
        passwordSecretName: "ranger-nifi-client-tls-password"
        passwordSecretKey: "password"
        issuerRef:
          name: "nifi-issuer"
          kind: "Issuer"
          group: "cert-manager.io"
        commonName: "ranger-nifi-client"
        dnsNames:
          - "ranger-nifi-client"
    connection:
      nifiUrl: "https://nifi-headless.<NAMESPACE>.svc.cluster.local:8443/nifi-api/resources"
      internalUrl: "https://nifi-headless.<NAMESPACE>.svc.cluster.local:8443/nifi-api/resources"
      authenticationType: "SSL"
      sslUseDefaultContext: "false"
      ssl:
        keystore: "/opt/ranger/certs/keystore.jks"
        keystoreType: "jks"
        keystorePasswordSecret:
          name: "ranger-nifi-client-tls-password"
          key: "password"
        truststore: "/opt/ranger/certs/truststore.jks"
        truststoreType: "jks"
        truststorePasswordSecret:
          name: "ranger-nifi-client-tls-password"
          key: "password"
      additionalConfigs:
        policy.download.auth.users: "nifi"

O certificado cliente é criado por cert-manager quando tlsClientCertificate.autoGenerate.enabled=true.
O Common Name configurado para o certificado deve bater com a identidade de administrador Ranger configurada no NiFi.

O chart também monta o material TLS em /opt/ranger/certs para que o Ranger use keystore.jks e truststore.jks.
Use o Service headless interno do NiFi quando os certificados dos nós incluírem esse hostname nos SANs.

Políticas declaradas

Cada integração aceita defaultPolicies.
Esse bloco permite criar políticas no Ranger Admin durante o bootstrap, quando configurado.

No caso de NiFi como authorizer, as políticas técnicas declaradas para o bootstrap devem permitir:

• CN=ranger-nifi-client em /resources.
• CN=nifi-controller em /controller e /system.
• Identidades dos nós NiFi em /proxy.

Essas políticas são técnicas e não substituem políticas humanas de acesso ao fluxo.
Crie políticas de usuários e grupos reais depois que LDAP/AD e UserSync estiverem validados.

Validação

Verifique se o job foi criado e concluiu com sucesso:

kubectl -n <NAMESPACE> get jobs
kubectl -n <NAMESPACE> logs job/<RELEASE_NAME>-ranger-integrations

No Ranger Admin, valide:

• serviço criado com o serviceName esperado;
• conexão do serviço sem erro;
• políticas declaradas em defaultPolicies aplicadas, quando configuradas;
• usuários técnicos criados quando a integração NiFi com mTLS estiver habilitada.

Solução de problemas

Sintoma	Possível causa	Verificação
Job não é criado	rangerIntegrations.configJob.enabled=false	Verifique o arquivo de valores aplicado
Job falha aguardando Ranger	Ranger Admin indisponível ou senha admin incorreta	Verifique pods, Service e Secret admin
Serviço não aparece no Ranger	Integração específica desabilitada	Verifique rangerIntegrations.<SERVICE_KEY>.enabled
NiFi mTLS falha	Senha JKS ausente ou certificado não emitido	Verifique Secrets e Certificate do cert-manager
Políticas não aplicam	Usuários/grupos não existem ou DN incorreto	Valide UserSync e nomes usados nas políticas

Depois de corrigir a causa, execute novo helm upgrade para recriar o hook de integração.