Modelo de privilégios

​

Identidades

• O certificado de cliente mTLS do connector, que usa o Organization ID da sua organização como common name, autentica cada daemon no seu connector endpoint. O clicklink clctl instances create usa o mesmo certificado e a mesma HMAC key ao chamar o endpoint.
• pcm_scraper e pcm_troubleshooter são os usuários do ClickHouse read-only com os quais o scraper e o solucionador de problemas se conectam. O executor não tem usuário do ClickHouse.
• As ServiceAccounts do Troubleshooter, uma por deployment provisionado, carregam as visualizações read-only do Kubernetes que uma sessão de suporte pode utilizar.
• pcm-executor é a ServiceAccount do Kubernetes usada pelo executor no ciclo de vida dos serviços gerenciados. Uma ValidatingAdmissionPolicy restringe suas gravações aos espaços de nomes dos serviços.
• pcm-platform é a identidade do executor para atualizações da plataforma. O seu clicklink clctl platform approve emite o token dele por 2 horas e nunca o renova; entre uma aprovação e outra, o executor não tem acesso de escrita à camada de plataforma.
• A IAM role por serviço (CH-S3-<service>-<region>-00-Role por padrão) é criada pelo clicklink clctl executor prepare com as suas credenciais. Ela é limitada aos buckets de dados e de backup daquele serviço e é confiada apenas pela ServiceAccount do Kubernetes daquele serviço, de modo que nem o executor nem o ClickHouse podem assumi-la.
• O instance profile da VM EC2 do connector assume a ECR puller role read-only do seu ambiente para acesso direto à plataforma, tanto para o login no chart quanto para as verificações de imagem. A CLI de aprovação usa o mesmo caminho de instance profile; perfis AWS da workstation ou credenciais de SSO não o substituem. Outros registries de chart no ECR usam credenciais AWS ambientes. Os image pulls acontecem nos seus nodes sob a própria pull role deles. O executor não detém credenciais para os seus buckets nem para o IAM e não faz chamadas ao S3 ou ao IAM. Consulte credenciais de registry.
• As suas próprias credenciais aplicam cada concessão: a concessão de acesso do executor no init --managed, os buckets e a role no prepare, a metade de permissões de cada atualização de plataforma no approve e a limpeza no teardown.

​

O que o conector pode fazer

​

Conexões de saída

​

Permissões do ClickHouse

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

​

RBAC do Kubernetes

​

Scraper e solucionador de problemas

​

Executor

​

Identidade da plataforma

​

O que o connector não pode fazer

• Nenhuma gravação em dados ou estado do ClickHouse. As concessões acima não contêm INSERT, nem DDL, nem privilégios de gerenciamento de usuários, settings ou controle de processos. A única concessão de classe system, o SYSTEM FLUSH LOGS do scraper, apenas faz com que as log tables persistam o que já está em buffer. O executor não possui usuário do ClickHouse. Nenhum componente pode modificar dados, esquemas, usuários ou settings por meio do ClickHouse.
• Nenhum exec. Nenhum RBAC contém pods/exec; nenhum componente pode executar comandos nos seus pods.
• Nenhuma gravação fora dos espaços de nomes de serviço e de plataforma. O scraper e o solucionador de problemas não possuem delete nem patch. Suas únicas mutações são o update de nome exato no próprio Secret de mTLS do connector e o create em serviceaccounts/token, que emite tokens de curta duração para seus próprios ServiceAccounts e não modifica nenhum objeto armazenado. A admission nega as gravações do executor fora do prefixo do serviço, e suas gravações de plataforma só existem enquanto um token emitido por você for válido.
• Nenhuma permissão para conceder permissões. Suas credenciais aplicam os Namespaces, CRDs, ServiceAccounts, RBAC, configurações de webhook e admission, PriorityClasses e StorageClass da plataforma durante o approve. A identidade de plataforma do executor não pode escalar privilégios, vincular nem personificar. Dentro de um espaço de nomes de serviço, o executor só pode criar Funções que concedam permissões que ele já detém.
• Nenhuma credencial para seus buckets ou IAM. O clicklink clctl executor prepare cria os buckets e a Função por serviço, e o clicklink clctl executor teardown os remove, ambos com suas credenciais. A Função só pode ser assumida pelos pods daquele serviço. Para acesso direto à plataforma, o executor usa o instance profile da VM EC2 do connector para assumir a Função de pull read-only do ECR, tanto para o login no chart quanto para as verificações de imagem. Outros registries de chart do ECR usam credenciais AWS ambientes; consulte identities. Suas únicas chamadas de API de nuvem vão para o ECR e o STS; ele não pode ler nem excluir seus dados.
• Nenhum conhecimento da senha do seu default user. O clicklink clctl executor prepare a gera do seu lado e a exibe uma única vez (ou o clicklink clctl instances create faz isso, quando você passa as entradas como flags). Apenas seus hashes são enviados, portanto nem o connector nem o ClickHouse Cloud conseguem recuperá-la.
• Nada de entrada. O ClickHouse Cloud nunca abre uma connection para dentro do seu ambiente. Os únicos caminhos de comando são os dois WebSockets de saída. O solucionador de problemas recusa todos os comandos, a menos que uma sessão de suporte habilitada por você esteja ativa. O executor aceita comandos de ciclo de vida apenas para os serviços cujo gerenciamento você solicitou ao ClickHouse, dentro dos escopos acima. Mesmo durante uma sessão, o solucionador de problemas é limitado dos dois lados. As consultas ao ClickHouse ficam restritas à allowlist de tabelas, que recusa query_log e text_log, de modo que eles nunca são concedidos. O acesso ao Kubernetes fica restrito às visualizações read-only e aos logs de pods concedidos pelas Funções com escopo de espaço de nomes.

​

O que exige sua ação

• Habilitar o modo gerenciado. O executor só é executado, e sua concessão no Kubernetes só existe, depois que você habilita o modo gerenciado no init; a concessão é aplicada com permissões de administrador do cluster. Consulte serviços gerenciados.
• Criar um serviço. O clicklink clctl executor prepare é executado com suas credenciais da AWS para criar os buckets e a IAM role, e o clicklink clctl instances create envia a definição. O ClickHouse Cloud não consegue criar um serviço no seu cluster sem os dois. Consulte criar um serviço.
• Atualizações da plataforma. Cada atualização dos componentes da plataforma só é aplicada depois que você executa clicklink clctl platform approve para aquele pacote exato; o token gerado expira após 2 horas e nunca é renovado. Consulte atualizações da plataforma.
• Limpeza após uma exclusão. Excluir um serviço remove apenas seus recursos do Kubernetes. O clicklink clctl executor teardown, executado com suas credenciais, remove a IAM role e, somente com flags explícitas, os dados e os backups. Consulte excluir um serviç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 de 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, ou verificá-lo com um bundle de CA informado em --gateway-ca, antes que os comandos da sessão se comuniquem com ele.
• Egress de rede. Em uma CNI que aplica regras, nenhum daemon alcança o endpoint do seu connector até que você liste os CIDRs dele em networkPolicy.allowEgressCIDRs. O executor também precisa dos CIDRs do Kubernetes API server (networkPolicy.apiserverCIDRs), que o init --managed deriva da VPC do cluster. Se os charts da plataforma vierem do Amazon ECR, adicione também os intervalos do ECR e do STS.

​

Como o acesso é atribuído

• Identidade da implantação. O common name do certificado de cliente mTLS é o ID da sua organização, e seu único DNS name está vinculado ao host do seu endpoint. Isso torna toda conexão de API atribuível à sua organização. A renovação é automática e ocorre dentro do daemon; nenhum operador manipula o material da chave.
• Integridade da requisição. Toda requisição de API também carrega uma assinatura HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) sobre o método, o caminho, o timestamp e o hash do corpo, usando o par de chaves emitido na inscrição.
• Identidade do operador. As chamadas ao gateway são atribuídas ao e-mail atestado pelo OIDC ID token do operador, verificado no JWKS do seu identity provider. Um nome autodeclarado nunca é considerado confiável quando há um token disponível.
• Comandos de ciclo de vida. O executor registra todo comando que recebe em seu armazenamento local, junto com sua origem (ClickHouse Cloud ou uma chamada local clicklink clctl), seu stage e seu resultado. Ele informa o resultado de volta pelo canal de comandos. Consulte o registro com clicklink clctl commands list e clicklink clctl commands get; veja a CLI reference.
• Aprovações de plataforma. O digest do pacote que você aprovou é registrado na ServiceAccount pcm-platform. Todo objeto aplicado por suas credenciais carrega um hash de conteúdo, que o executor verifica antes de gravar qualquer coisa. Um pacote com qualquer outro digest é recusado.
• Trilha de auditoria. Todo comando de session, aceito ou bloqueado, é anexado ao log de auditoria NDJSON com a identidade da organização obtida do canal de comandos. As chamadas ao gateway são registradas como linhas estruturadas clctl.gateway no log do solucionador de problemas, com o e-mail atestado do operador. Alterações de session locais na VM registram o usuário do host em session.json. Consulte o log de auditoria com clicklink clctl troubleshoot audit tail; veja a CLI reference.

​

Padrões de minimização de dados

• A query_log fica fora dos scrapes por padrão. Suas colunas contêm SQL bruto com valores literais, que podem incluir dados pessoais ou secrets. Ela não sai da sua fronteira a menos que você a adicione.
• O solucionador de problemas lê apenas tabelas na allowlist. query_log e text_log são recusadas na própria configuração da allowlist, de modo que nunca são concedidas e o histórico de consultas nunca fica legível. A allowlist padrão inclui system.processes (texto das consultas em execução); reduza-a (troubleshooter.allowedTables no Kubernetes, troubleshooter.allowed_tables em uma VM) se isso precisar permanecer oculto durante as sessões.
• Toda a saída do solucionador de problemas é redigida com patterns integrados e com quaisquer outros que você definir. Os integrados cobrem endereços IPv4 e IPv6, bearer tokens, chaves de acesso da AWS, e-mails, JWTs, chaves privadas SSH e credenciais em strings de conexão. Diante de um arquivo de patterns inválido, o daemon se recusa a iniciar em vez de executar sem redação.
• O status do managed service é apenas metadata. O executor informa o estado de um serviço, a contagem de réplicas, as versões e os resultados dos comandos. Ele nunca lê as tabelas nem os buckets do serviço.
• As credenciais são minimizadas em repouso. O SQL de provisioning contém hashes bcrypt, nunca senhas em plaintext. A senha do default user de um managed service é exibida uma única vez e sai apenas como hashes. O enrollment token nunca é gravado na linha de comando, em disco ou em logs. As chaves ficam em Kubernetes Secrets ou em arquivos com modo 0600.