Segurança — Padrões Gerais
Esta página apresenta os principais padrões de segurança usados nos componentes TDP Kubernetes.
Ela não substitui as páginas específicas de segurança de cada componente. Use esta página para entender os conceitos gerais e consulte a página do componente para aplicar os parâmetros corretos, nomes de Secrets, arquivos de valores e exemplos completos.
Como usar esta página
Use esta tabela como mapa rápido de onde cada decisão de segurança deve ser tratada. Ela não é uma taxonomia rígida: a mesma configuração pode envolver mais de uma camada.
| Dúvida ou decisão | O que verificar | Onde aprofundar |
|---|---|---|
| Credenciais sensíveis | Palavras-passe, tokens, chaves de acesso, palavras-passe de bind, keystores, truststores e referência a Secrets existentes | Credenciais e Kubernetes Secrets; página de segurança ou integração do componente |
| Login de usuários | LDAP, Active Directory, SSO, conta interna e escopo da autenticação | Autenticação de usuários; segurança do componente |
| TLS de entrada | HTTPS via Ingress ou Gateway API, hostname, certificado e Secret TLS | TLS no Ingress ou Gateway API; Configuração de Ingress |
| TLS interno ou de integração | LDAPS, conexão segura com base de dados, S3, listeners, APIs internas, keystores e truststores | TLS na aplicação; TLS em integrações; segurança ou integração do componente |
| Permissões e políticas | Autorização da aplicação, políticas Ranger, usuários, grupos e aplicação das políticas em runtime | Autorização e políticas; Segurança - Ranger quando aplicável |
| Controlo de rede | Origens e destinos permitidos, tráfego entre namespaces e exposição de Services internos | NetworkPolicy e controlo de acesso à rede; página do componente |
| Auditoria | Logs de acesso, falhas de autenticação, operações sensíveis e rastreabilidade operacional | Auditoria e rastreabilidade; página do componente |
Princípios gerais
Antes de configurar segurança em qualquer componente, observe estes princípios:
- não versionar palavras-passe em texto plano em ficheiros de valores;
- preferir Kubernetes Secrets para credenciais sensíveis;
- utilizar hostnames, certificados e Secrets compatíveis com o ambiente real;
- validar se a configuração pertence ao componente, ao Ingress ou a uma integração externa;
- consultar a página específica do componente antes de aplicar parâmetros de segurança.
Credenciais e Kubernetes Secrets
Credenciais sensíveis, como palavras-passe de base de dados, tokens, chaves de acesso, palavras-passe de bind LDAP e palavras-passe de keystore, devem ser armazenadas em Kubernetes Secrets.
Os componentes TDP permitem geralmente referenciar Secrets existentes por parâmetros como existingSecret, secretKeyRef, passwordSecret.name ou estruturas equivalentes documentadas no componente.
Prefira esta abordagem a fornecer palavras-passe directamente nos valores do componente.
Criar um Secret
kubectl -n <NAMESPACE> create secret generic <SECRET_NAME> --from-literal=<CONFIG_KEY>='<CONFIG_VALUE>'
Não inclua palavras-passe em texto plano em ficheiros de valores commitados no Git. Utilize referências a Secrets ou ferramentas próprias de gestão de Secrets.
Gestão avançada de Secrets
Em ambientes de produção, considere ferramentas especializadas para gestão de Secrets:
| Ferramenta | Uso |
|---|---|
| Sealed Secrets | Permite versionar Secrets criptografados no Git |
| External Secrets Operator | Sincroniza Secrets a partir de cofres externos |
| HashiCorp Vault | Centraliza credenciais e políticas de acesso |
Rotação e revogação de credenciais
Credenciais de longa duração precisam de ciclo de rotação definido. Ao rodar:
- Actualize ou recrie o Secret Kubernetes com as novas credenciais.
- Reinicie os pods que consomem esse Secret (variáveis de ambiente ou ficheiros montados).
- Valide que as aplicações estão a operar com as novas credenciais antes de descartar as antigas.
A revogação prática em Kubernetes é operacional: remover ou substituir o Secret, reiniciar workloads e bloquear caminhos de rede quando necessário. O tempo de exposição após comprometimento depende de quão rapidamente os Secrets são actualizados e os pods são reiniciados.
Consulte a página de segurança do componente para saber quais Secrets e pods precisam ser reiniciados ao rodar credenciais específicas.
Autenticação de usuários
Alguns componentes TDP permitem autenticação integrada a LDAP, Active Directory, SSO ou outro provedor externo.
A forma de configuração varia conforme o componente. Ela pode envolver:
- parâmetros diretos nos valores do componente;
- arquivo adicional de valores aplicado como overlay Helm;
- configuração própria da aplicação;
- integração com provedor intermediário de autenticação;
- Kubernetes Secrets para armazenar credenciais de bind ou client secrets.
Por isso, não existe um único modelo LDAP ou SSO aplicável a todos os componentes.
Em componentes que utilizam LDAP ou AD como referência de ciclo de vida sem validação server-side de credenciais (por exemplo, sem Kerberos), desactivar uma conta no directório não revoga automaticamente credenciais já distribuídas. A revogação é operacional: remover os Secrets dos workloads, reiniciá-los e, quando necessário, bloquear o acesso por NetworkPolicy ou regras de rede.
Consulte a página de segurança do componente para confirmar:
- se LDAP, AD ou SSO são suportados;
- quais parâmetros devem ser usados;
- quais Secrets precisam existir;
- se há overlay Helm específico;
- se a autenticação se aplica à aplicação inteira ou apenas a uma interface web.
Overlay Helm para autenticação
Alguns componentes podem disponibilizar arquivos de valores adicionais para autenticação, como overlays LDAP.
Quando documentado pelo componente, aplique o overlay junto ao arquivo principal, usando -f <VALUES_FILE> e -f <LDAP_VALUES_FILE> no comando Helm do componente.
Use overlays apenas quando eles forem documentados pelo componente. Nem todos os componentes usam esse padrão.
TLS e certificados
A configuração de TLS pode ocorrer em camadas diferentes. Essas camadas não devem ser confundidas.
TLS no Ingress ou Gateway API
Quando um componente é exposto por Ingress ou Gateway API, o TLS pode ser terminado no Ingress Controller ou no Gateway.
Esse tipo de TLS protege o acesso externo ao serviço, por exemplo:
https://ranger.empresa.com.br
A configuração costuma envolver hostname, Secret TLS, certificado e parâmetros de Ingress ou Gateway API.
Para detalhes, consulte Configuração de Ingress.
Rate limiting no Ingress
Além do TLS, configure limites de pedidos para proteger endpoints expostos externamente contra utilização abusiva. Ingress Controllers como o NGINX suportam anotações específicas para esse controlo:
annotations:
nginx.ingress.kubernetes.io/limit-rps: "100"
nginx.ingress.kubernetes.io/limit-connections: "10"
Consulte a documentação do Ingress Controller em utilização para as anotações disponíveis. Os valores adequados dependem do componente e do perfil de utilização esperado.
TLS na aplicação
Alguns componentes também podem exigir TLS diretamente na aplicação, em listeners, APIs internas ou portas específicas.
Esse tipo de configuração depende do componente e pode envolver:
- keystores;
- truststores;
- certificados internos;
- portas específicas;
- parâmetros próprios do componente.
Consulte a página de segurança do componente para verificar se ele documenta TLS em nível de aplicação.
TLS em integrações
Algumas integrações externas também podem exigir TLS, por exemplo:
- LDAPS para integração com diretório corporativo;
- conexão segura com banco de dados;
- conexão segura com armazenamento S3-compatível;
- comunicação segura entre componentes.
Nesses casos, a configuração pode pertencer à página de segurança do componente ou à página de integração correspondente.
Autorização e políticas
Autenticação e autorização são etapas diferentes.
A autenticação define quem é o usuário.
A autorização define o que esse usuário pode acessar ou executar.
Alguns componentes possuem autorização própria. Outros podem ser integrados a mecanismos externos de autorização, como o Apache Ranger, quando essa integração estiver prevista e configurada corretamente.
Quando o Ranger for usado, há dois lados que devem ser considerados:
| Lado | O que significa |
|---|---|
| Ranger Admin | Cadastro de serviços, políticas, usuários e grupos |
| Componente integrado | Configuração necessária para consultar ou aplicar políticas |
O cadastro de um serviço no Ranger Admin não substitui, por si só, a configuração do componente para aplicar políticas em tempo de execução.
Para detalhes de políticas, UserSync, LDAP e integrações do Ranger, consulte Segurança - Ranger.
Credenciais para integrações externas
Alguns componentes precisam acessar serviços externos ou complementares, como bancos de dados, armazenamento de objetos, serviços S3-compatíveis ou APIs.
Estas integrações normalmente exigem credenciais específicas, que devem ser armazenadas em Kubernetes Secrets.
Exemplo genérico para credenciais S3-compatíveis:
kubectl -n <NAMESPACE> create secret generic <S3_SECRET_NAME> --from-literal=access-key='<S3_ACCESS_KEY>' --from-literal=secret-key='<S3_SECRET_KEY>'
O modo de referência ao Secret varia consoante o componente. Consulte a página de integração ou de segurança do componente antes de aplicar a configuração.
Para detalhes sobre conexões S3-compatíveis, consulte Configuração de Integração.
NetworkPolicy e controle de acesso à rede
NetworkPolicy restringe o tráfego de entrada e saída de pods num cluster Kubernetes. Em ambientes de produção, é uma camada essencial de defesa em profundidade, complementar ao TLS e à autenticação da aplicação.
Para componentes TDP, considere:
- Permitir tráfego de entrada somente dos namespaces e ServiceAccounts que realmente precisam do serviço.
- Bloquear tráfego de saída desnecessário de pods com dados sensíveis.
- Tratar Services internos (não expostos via Ingress) com a mesma atenção que serviços externos.
A aplicação de NetworkPolicy depende do plugin de rede (CNI) em utilização no cluster. Verifique se o CNI do ambiente suporta e aplica NetworkPolicies antes de depender desse controlo como única camada de protecção.
Consulte a página de segurança do componente para orientações sobre quais portas e origens de tráfego devem ser permitidas.
Auditoria e rastreabilidade
Active o audit logging nos componentes que suportam essa funcionalidade. Os logs de auditoria registam acessos, falhas de autenticação e operações sensíveis, sendo essenciais para investigação de incidentes e conformidade.
Cada componente TDP documenta, na sua página de segurança, se e como o audit logging pode ser activado. Direccionando esses logs para a solução de observabilidade do ambiente, é possível centralizar alertas e análises.
Princípios gerais de monitoramento:
- Monitorize falhas de autenticação — volume elevado pode indicar tentativa de acesso não autorizado.
- Monitorize acessos a dados sensíveis fora do horário operacional normal.
- Retenha logs de auditoria por um período compatível com as políticas do ambiente.
Próximos passos
Para configurar segurança em um componente específico, acesse a página de segurança correspondente no índice de Configuração.
Use esta página como referência geral para entender os padrões de segurança do TDP Kubernetes. Os parâmetros exatos devem sempre ser confirmados na documentação específica do componente.