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 | Senhas, tokens, chaves de acesso, senhas 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 banco, 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 |
| Controle de rede | Origens e destinos permitidos, tráfego entre namespaces e exposição de Services internos | NetworkPolicy e controle 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 senhas em texto plano em arquivos de valores;
- preferir Kubernetes Secrets para credenciais sensíveis;
- usar 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 senhas de banco de dados, tokens, chaves de acesso, senhas de bind LDAP e senhas de keystore, devem ser armazenadas em Kubernetes Secrets.
Os componentes TDP geralmente permitem referenciar Secrets existentes por parâmetros como existingSecret, secretKeyRef, passwordSecret.name ou estruturas equivalentes documentadas no componente.
Prefira essa abordagem a fornecer senhas diretamente nos valores do componente.
Criar um Secret
kubectl -n <NAMESPACE> create secret generic <SECRET_NAME> --from-literal=<CONFIG_KEY>='<CONFIG_VALUE>'
Não inclua senhas em texto plano em arquivos de valores commitados no Git. Use 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 rotacionar:
- Atualize ou recrie o Secret Kubernetes com as novas credenciais.
- Reinicie os pods que consomem esse Secret (variáveis de ambiente ou arquivos montados).
- Valide que as aplicações estão operando 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 atualizados 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 rotacionar 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 usam LDAP ou AD como referência de ciclo de vida sem validação server-side de credenciais (por exemplo, sem Kerberos), desabilitar uma conta no diretó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 requisição para proteger endpoints expostos externamente contra uso abusivo. Ingress Controllers como NGINX suportam anotações específicas para esse controle:
annotations:
nginx.ingress.kubernetes.io/limit-rps: "100"
nginx.ingress.kubernetes.io/limit-connections: "10"
Consulte a documentação do Ingress Controller em uso para as anotações disponíveis. Os valores adequados dependem do componente e do perfil de uso 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.
Essas 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 conforme o componente. Consulte a página de integração ou 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 em um 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 uso no cluster. Verifique se o CNI do ambiente suporta e aplica NetworkPolicies antes de depender desse controle como única camada de proteção.
Consulte a página de segurança do componente para orientações sobre quais portas e origens de tráfego devem ser liberadas.
Auditoria e rastreabilidade
Habilite audit logging nos componentes que suportam esse recurso. Os logs de auditoria registram acessos, falhas de autenticação e operações sensíveis, sendo essenciais para investigação de incidentes e conformidade.
Cada componente TDP documenta, em sua página de segurança, se e como o audit logging pode ser habilitado. Direcionando esses logs para a solução de observabilidade do ambiente, é possível centralizar alertas e análises.
Princípios gerais de monitoramento:
- Monitore falhas de autenticação — volume elevado pode indicar tentativa de acesso não autorizado.
- Monitore acessos a dados sensíveis fora do horário operacional normal.
- Retenha logs de auditoria por 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.