O que o conector pode fazer
Conexões de saída
Para conexões de entrada, o conector expõe apenas portas locais de integridade e métricas, além do gateway de sessão opcional. Nenhum outro serviço fica escutando, e o ClickHouse Cloud nunca se conecta ao seu ambiente: ele só pode responder ao WebSocket de saída do troubleshooter.
Permissões do ClickHouse
SYSTEM FLUSH LOGS do scraper, listada abaixo, que não permite ler nem modificar nada; ela apenas força as tabelas de logs a persistirem as entries que já estão no buffer. Os usuários são criados com IDENTIFIED WITH bcrypt_hash, portanto, no SQL de provisionamento existe apenas um hash bcrypt com salt; a senha em texto simples fica somente no arquivo de credenciais que o daemon lê em runtime. As permissões são exatamente estas, com os conjuntos de tabelas default:
READ ON REMOTE é necessário porque as consultas de scrape envolvem cada tabela de sistema em clusterAllReplicas(). SYSTEM FLUSH LOGS deve ser concedido no escopo global porque o ClickHouse rejeita escopos mais restritos para esse privilégio; o ClickHouse só o considera para tabelas de sistema *_log, portanto, a concessão é mais ampla do que a capacidade efetiva.
system.user_directories para ambos os usuários serve a um único diagnóstico: clicklink clctl preflight é executado com as credenciais do próprio conector e verifica como a instância armazena os usuários do ClickHouse (de forma replicada ou local). A tabela contém metadados de configuração do armazenamento de usuários, não dados de usuários, e não está incluída nem no conjunto de scrape nem na allowlist da tabela de sessão; portanto, nenhum caminho de saída de scrape ou sessão a lê. Sem essa permissão, essa única verificação de preflight informa que foi ignorada, e todo o restante prossegue.
Além do SELECT por tabela, a única permissão no nível do sistema é SYSTEM FLUSH LOGS do scraper: ela força as tabelas de sistema *_log a persistir no disco as entradas em buffer para que as coletas vejam dados atuais e não faz mais nada; o ClickHouse só a aplica a tabelas de log, embora essa permissão só possa ser concedida no escopo global. Não há permissões de INSERT, DDL, gerenciamento de usuários, configurações nem controle de processos. Quando uma segunda implantação do conector compartilha uma instância, seus usuários recebem um sufixo (pcm_scraper_<suffix>) com o mesmo conjunto de permissões.
RBAC do Kubernetes
O que o conector não pode fazer
- Não grava dados nem estado no ClickHouse. As permissões acima não incluem
INSERT, DDL nem privilégios de gerenciamento de usuários, configurações ou controle de processos; a única permissão da classe SYSTEM,SYSTEM FLUSH LOGSdo scraper, apenas faz com que as tabelas de logs persistam o que já mantêm em buffer. O conector não pode modificar dados, schemas, usuários ou configurações. - Não executa comandos. O RBAC não inclui
pods/exec; o conector não pode executar comandos nos seus pods. - Não exclui nem aplica patches. O RBAC permite duas mutações: o
updatecom nome exato no Secret mTLS do próprio conector ecreateemserviceaccounts/token, que gera tokens de curta duração para as ServiceAccounts do próprio conector e não modifica nenhum objeto armazenado. - Sem escopo de cluster. Cada Role é vinculada a um espaço de nomes; o conector não pode listar nem ler recursos fora dos espaços de nomes aos quais você concedeu acesso.
- Nada de entrada. O ClickHouse Cloud nunca abre uma conexão com o seu ambiente. O único canal de comandos é o WebSocket de saída do troubleshooter, que recusa todos os comandos, a menos que esteja ativa uma sessão de suporte habilitada por você. Mesmo durante uma sessão, o escopo é limitado em ambos os lados: as consultas do ClickHouse ficam restritas à allowlist de tabelas, e o validador nega
query_logetext_logindependentemente da configuração; separadamente, o acesso ao Kubernetes fica limitado às visualizações somente leitura e aos logs de pods concedidos pelas Roles com escopo de espaço de nomes.
O que exige sua ação
- Sessões de suporte. A solução interativa de problemas ocorre apenas em uma sessão habilitada por você, limitada a 4 horas por padrão e a, no máximo, 24 horas. Desabilitá-la tem efeito imediato. Consulte as sessões de suporte.
- A allowlist de operadores. Toda solicitação ao gateway deve incluir um token OIDC cujo e-mail atestado conste na sua allowlist. Uma allowlist vazia bloqueia o acesso. Você gerencia a lista; consulte o guia de configuração.
- Exposição do gateway. O gateway da sessão permanece desativado até que você o habilite e só pode ser acessado por redirecionamento de porta, a menos que você habilite uma Entrada. Em uma VM, cada operador deve fixar a impressão digital do certificado autossinado antes que os comandos da sessão possam se comunicar com ele.
- Egress de rede. Em uma CNI que aplica regras, o conector não tem egress até que você inclua na allowlist os CIDRs de endpoint na NetworkPolicy do chart.
Como o acesso é atribuído
- Identidade da implantação. O nome comum do certificado de cliente mTLS é o ID da sua org, com um único nome DNS associado ao host do endpoint. Assim, cada conexão de API pode ser atribuída à sua org. A renovação é automática e realizada no daemon; nenhum operador manipula o material de chave.
- Integridade da solicitação. Cada solicitação de API também inclui uma assinatura HMAC-SHA256 (
Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) calculada com base no método, no path, no timestamp e no hash do body, usando o par de chaves emitido na inscrição. - Identidade do operador. As chamadas do gateway são atribuídas ao e-mail atestado pelo token de ID OIDC do operador, verificado com base no JWKS do seu provedor de identidade; um nome autodeclarado nunca é considerado confiável quando há um token disponível.
- Trilha de auditoria. Cada chamada do gateway e cada comando de solução de problemas, aceito ou bloqueado, é adicionado ao log de auditoria NDJSON: entradas do gateway com o e-mail atestado do operador, alterações de sessão local da VM com o usuário do host que as invocou e comandos de sessão com a identidade da org transportada pelo canal autenticado. Leia-o com
clicklink clctl troubleshoot audit tail; consulte a referência da CLI.
Padrões de minimização de dados
query_logé excluída das coletas por padrão. Suas colunas contêm SQL bruto com valores literais, que podem incluir dados pessoais ou segredos, portanto essas informações não ultrapassam sua fronteira, a menos que você a adicione deliberadamente.- O troubleshooter lê apenas tabelas incluídas na allowlist, e o validador bloqueia
query_logetext_logincondicionalmente, portanto o histórico de consultas nunca pode ser lido. A allowlist padrão incluisystem.processes(texto de consulta em execução); restrinja a allowlist de tabelas de sessão (troubleshooter.allowedTablesno Kubernetes,troubleshooter.allowed_tablesem uma VM) se isso precisar permanecer oculto durante as sessões. - Toda a saída do troubleshooter é mascarada com padrões integrados para endereços IPv4 e IPv6, tokens Bearer, chaves de acesso da AWS, e-mails, JWTs, chaves privadas SSH e credenciais de strings de conexão, além de quaisquer padrões que você definir. O daemon se recusa a iniciar se o arquivo de padrões for inválido, em vez de ser executado sem mascaramento.
- As credenciais são minimizadas em repouso. O SQL de Provisioning contém hashes bcrypt, nunca senhas em texto simples; o token de inscrição nunca é gravado na linha de comando, no disco ou nos logs; as chaves ficam em Kubernetes Secrets ou em arquivos com modo 0600.