Edição de 27/09: Kubernetes RBAC — rever o acesso que a tarefa usa
Uma revisão estreita liga identidade, bindings e pedidos necessários, sem confundir leitura com baixo risco ou uma role nova com redução de privilégios.
- Autoria
- Redação Velqory
- Dia recuperado
- 2026-09-27
- Publicação real
- 2026-10-05
- Revisão editorial e verificação
- 05/10/2026 · Europe/Lisbon
- Natureza
- Análise retrospetiva publicada a 5 de outubro; não representa publicação original nessa data. Propostas operacionais originais da Velqory, não testadas; nenhum ensaio ou experiência interna é alegado.
- Revisão
- Revalidar documentação e critérios antes de qualquer intervenção e quando mudar a versão ou a configuração.
Em resumo
Uma revisão estreita liga identidade, bindings e pedidos necessários, sem confundir leitura com baixo risco ou uma role nova com redução de privilégios.
- Reveja todas as concessões aplicáveis à identidade, não apenas a Role nova.
- Separe leitura de estado, leitura de Secrets e criação de workloads.
- Exija provas de pedidos recusados, além dos pedidos que a tarefa necessita.
Que operação justifica cada privilégio?
Esta análise recupera a edição de 27 de setembro, com publicação real em 5 de outubro. A pergunta é para responsáveis de plataforma e aplicações: uma conta de serviço precisa de observar um recurso específico ou recebeu capacidade para alterar todo um namespace porque isso resolveu uma dificuldade de instalação?
Propomos rever uma identidade de cada vez, começando por uma tarefa concreta. Para um coletor hipotético de estado de tarefas, escreva recursos, verbos e âmbito necessários. O desenho abaixo não foi implementado nem testado pela Velqory. Não é um manifesto pronto a aplicar, uma auditoria de cliente ou uma declaração de segurança do cluster.
Uma regra estreita não anula concessões largas
A referência oficial explica que as permissões RBAC são aditivas: não existem regras de negação. A nossa interpretação operacional é que acrescentar uma Role limitada não demonstra redução do acesso se outra concessão continuar presente.
Proposta Velqory: guarde a cadeia completa entre a conta escolhida, os sujeitos dos bindings e as regras referenciadas. Inclua concessões por grupos aplicáveis. Compare o conjunto efetivo com a tarefa, não apenas o ficheiro mais recente. O responsável de plataforma deve justificar cada caminho adicional ou registá-lo como divergência a corrigir, antes de declarar concluída a revisão.
Leia o binding, não apenas o nome da role
A documentação distingue RoleBinding, que concede permissões num namespace, de ClusterRoleBinding, com âmbito de cluster. Uma RoleBinding pode referenciar uma ClusterRole para conceder as permissões no namespace da binding. O nome ClusterRole não basta para concluir qual é o acesso concedido.
Propomos que o dossier identifique a conta e o namespace do sujeito, o namespace da binding e a role referenciada em campos separados. Depois, escreva o pedido de API que a aplicação necessita. Evite uma conclusão global como «só leitura»: diga leitura de quê, onde e através de que concessões. Uma referência ambígua deve bloquear a aceitação.
Ler não significa baixo impacto
As boas práticas oficiais alertam que get, list e watch de Secrets podem revelar o seu conteúdo. Num cenário inteiramente hipotético, um coletor de estado recebe list de todos os recursos para facilitar a configuração. Se isso incluir Secrets, a descrição «apenas observa» não limita aquilo que lê.
Para este coletor, a nossa proposta é excluir leitura de Secrets e substituir a autorização ampla por um desenho ligado aos recursos de estado realmente necessários. Não recolha conteúdos secretos para demonstrar a revisão. Guarde referências e decisões de autorização com dados sintéticos num ambiente aprovado. Uma resposta permitida onde se esperava recusa é motivo para reprovar o desenho.
Inclua o caminho de criação de workloads
A documentação de boas práticas avisa que criar workloads num namespace pode dar acesso indireto a recursos montáveis e aos níveis de acesso das contas de serviço desse namespace. Portanto, rever apenas leitura direta de Secrets não cobre esse caminho.
Propomos excluir criação de workloads do coletor, salvo necessidade documentada e avaliação separada. O dono da aplicação deve descrever a falha funcional que resultaria dessa exclusão; «o pacote pede» não basta. Se existir necessidade legítima, trate-a como uma decisão própria, com recursos permitidos e fronteiras avaliadas. Não afirme que a ausência dessa permissão elimina todos os caminhos de escalada.
Aceite uma tarefa e recuse os desvios
A matriz é uma proposta original não testada. O operador recolhe as decisões; um responsável distinto aceita o âmbito. Preserve a configuração anterior para analisar diferenças, não para repor silenciosamente privilégios excessivos quando surgir uma falha.
Depois de um ensaio autorizado, documente pedidos permitidos e recusados, configuração e identidade usadas. A aceitação vale para aquela tarefa e versão. Uma nova integração, binding ou necessidade de escrita exige nova revisão. Para a PME, esta delimitação permite discutir o acesso com o prestador sem inventar uma certificação de segurança.
Aceitação do coletor de estado hipotético
Desenho Velqory não implementado nem testado.
| Pedido | Dono da decisão | Evidência | Passa / falha |
|---|---|---|---|
| Leitura necessária | Dono da aplicação | Recurso, verbo e namespace | Passa se a tarefa funcionar no âmbito definido; falha se faltar prova. |
| Concessões adicionais | Plataforma | Cadeia de bindings e regras | Passa com conjunto justificado; falha com concessão desconhecida. |
| Secrets | Segurança | Decisão de autorização sem conteúdo real | Passa com recusa prevista; falha com leitura indevida. |
| Criar workloads | Plataforma e aplicação | Necessidade ou exclusão explícita | Passa sem criação desnecessária; falha com caminho não avaliado. |
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.