Versão 3.0

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 registo 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, regista ou atualiza os serviços correspondentes no Ranger Admin e cria as políticas declaradas em defaultPolicies, quando configuradas.

Sem esse job, esse registo precisa de 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 respetivo 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 registo no Ranger Admin, habilite esse parâmetro no seu ficheiro 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.*`	Partilhado com subcharts que consomem valores globais

Use o escopo que corresponde ao pacote implantado.

Quando o registo 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.
Palavra-passe 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 registado 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 revistas antes de aplicar em ambiente partilhado.

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 regista serviços e políticas no Ranger Admin.

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

Exemplos de integrações

As secções seguintes mostram exemplos de configuração aceites por rangerIntegrations.

Elas não devem ser lidas como uma lista conceptual fixa de tudo que o Apache Ranger pode proteger.

Kafka

A configuração de Kafka regista 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 registo 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.

Reveja 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 regista 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 registo não substitui a configuração do controlo de acesso Ranger no chart do Trino; o Trino também precisa de 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 registado 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 regista 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 registo 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.

Ficheiro de overlay dedicado

Para integração do NiFi com o Ranger como authorizer, utilize o ficheiro 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 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 registo do serviço no Ranger Admin precisa de ser compatível com o fluxo de mTLS entre Ranger e NiFi.

Nesse cenário, o Ranger acede ao 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 palavra-passe 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 palavra-passe 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"
    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"
    connection:
      nifiUrl: "https://nifi-headless.<NAMESPACE>.svc.cluster.local:8443/nifi-api/resources"
      authenticationType: "SSL"
      sslUseDefaultContext: "false"
      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.

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 flow.

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 a criação do serviço, estado da conexão, políticas declaradas em defaultPolicies quando configuradas e usuários técnicos quando NiFi mTLS estiver habilitado.

Resolução de problemas

Sintoma	Possível causa	Verificação
Job não é criado	`rangerIntegrations.configJob.enabled=false`	Verifique o ficheiro de valores aplicado
Job falha aguardando Ranger	Ranger Admin indisponível ou palavra-passe 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	Palavra-passe 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.

Visão geral das integrações​

Padrão de configuração​

Pré-requisitos​

Job de integrações​

Exemplos de integrações​

Kafka​

Trino​

NiFi genérico​

NiFi como authorizer via Ranger​

Políticas declaradas​

Validação​

Resolução de problemas​