Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego

Jenn GileDiretor de Marketing de Produto, NGINX

Editor – Este post faz parte de uma série de 10 partes:

1. Reduza a complexidade com Kubernetes pronto para produção
2. Como aumentar a resiliência no Kubernetes com o gerenciamento avançado de tráfego
3. Como melhorar a visibilidade no Kubernetes
4. Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego (este post)
5. Guia para escolher um controlador de Ingress, parte 1: identifique seus requisitos
6. Guia para escolher um controlador de Ingress, Parte 2: riscos e preparação para o futuro
7. Um guia para escolher um controlador de Ingress, parte 3: código aberto vs. padrão vs. comercial
8. Um guia para escolher um controlador de Ingress, parte 4: opções de controladores de Ingress da NGINX
9. Como escolher uma malha de serviços
10. Teste de desempenho de controladores de Ingress NGINX em um ambiente de nuvem Kubernetes dinâmico

Você também pode baixar a coleção completa de artigos como um e-book gratuito – Levando o Kubernetes do teste à produção.

Conforme discutido em Proteja aplicações nativas da nuvem sem perder velocidade, observamos três fatores que tornam as aplicações nativas da nuvem mais difíceis de proteger do que as aplicações tradicionais:

1. A entrega de aplicações nativas da nuvem causa a proliferação de ferramentas e oferece serviços de nível empresarial inconsistentes
2. Os custos de entrega de aplicações nativas da nuvem podem ser altos e imprevisíveis
3. As equipes de SecOps enfrentam dificuldades para proteger aplicações nativas da nuvem e entram em conflito com as equipes de DevOps

Embora os três fatores possam afetar igualmente a segurança, o terceiro pode ser o problema mais difícil de resolver, talvez por ser o mais “humano”. Quando a equipe de SecOps não consegue ou não tem autonomia para proteger aplicações nativas da nuvem, algumas das consequências são óbvias (vulnerabilidades e violações), mas outras permanecem ocultas, incluindo a redução da agilidade e a paralisação da transformação digital.

Vamos analisar mais a fundo esses custos ocultos. As organizações escolhem o Kubernetes por sua promessa de agilidade e redução de custos. Porém, quando ocorrem incidentes de segurança em um ambiente Kubernetes, a maioria das organizações retira suas implantações do Kubernetes do ambiente de produção. Isso atrasa as iniciativas de transformação digital essenciais para o futuro da organização, sem falar no desperdício de esforços de engenharia e de dinheiro. A conclusão lógica é: se você pretende levar o Kubernetes do ambiente de testes para o de produção, a segurança deve ser considerada um componente estratégico cuja responsabilidade cabe a todos na organização.

Neste post, abordamos seis casos de uso de segurança que podem ser solucionados com ferramentas de gerenciamento de tráfego do Kubernetes, permitindo que as equipes de SecOps colaborem com as de DevOps e NetOps para proteger melhor seus aplicativos e APIs nativos da nuvem. Uma combinação dessas técnicas costuma ser usada para criar uma estratégia de segurança abrangente, desenvolvida para manter aplicativos e APIs seguros e, ao mesmo tempo, minimizar o impacto para os clientes.

1. Resolva CVEs rapidamente para evitar ataques cibernéticos
2. Impeça ataques do OWASP Top 10 e de negação de serviço
3. Transfira a autenticação e a autorização dos aplicativos
4. Configure o autoatendimento com controles de segurança
5. Implemente a criptografia de ponta a ponta
6. Garanta que os clientes estejam usando uma cifra robusta com uma implementação confiável

Terminologia de segurança e identidade

Antes de abordarmos os casos de uso, confira uma breve visão geral de alguns termos de segurança e identidade que você encontrará ao longo deste artigo.

• Autenticação e autorização – Funções necessárias para garantir que apenas os usuários e serviços “certos” tenham acesso a back-ends ou componentes de aplicativos:
  • Autenticação – Verificação da identidade para garantir que os clientes que fazem solicitações sejam quem afirmam ser. Realizada por meio de tokens de identidade, como senhas ou JSON Web Tokens (JWTs).
  • Autorização – Verificação da permissão para acessar um recurso ou uma função. Realizada por meio de tokens de acesso, como atributos da Camada 7, incluindo cookies de sessão, IDs de sessão, IDs de grupo ou conteúdo de tokens.
• Vulnerabilidades e Exposições Críticas (CVEs) – Um banco de dados de falhas divulgadas publicamente “em um componente de software, firmware, hardware ou serviço, resultantes de uma vulnerabilidade que pode ser explorada, causando um impacto negativo na confidencialidade, integridade ou disponibilidade de um ou mais componentes afetados” (https://www.cve.org/). As CVEs podem ser descobertas pelos desenvolvedores responsáveis pela ferramenta, por um testador de invasão, por um usuário ou cliente ou por alguém da comunidade (como um “caçador de bugs”). É prática comum dar ao proprietário do software tempo para desenvolver uma correção antes que a vulnerabilidade seja divulgada publicamente, para não dar vantagem a agentes mal-intencionados.
• Ataque de negação de serviço (DoS) – Um ataque no qual um agente mal-intencionado sobrecarrega um site com solicitações (TCP/UDP ou HTTP/HTTPS) com o objetivo de fazê-lo sair do ar. Como os ataques DoS afetam a disponibilidade, sua principal consequência é prejudicar a reputação do alvo. Um ataque distribuído de negação de serviço (DDoS), no qual várias fontes têm como alvo a mesma rede ou serviço, é mais difícil de combater devido à rede potencialmente grande de invasores. A proteção contra DoS requer uma ferramenta que identifique e impeça ataques de forma adaptativa. Saiba mais em O que é um ataque distribuído de negação de serviço (DDoS)?
• Criptografia de ponta a ponta (E2EE) – A prática de criptografar totalmente os dados durante o trajeto do usuário até o aplicativo e de volta. A E2EE requer certificados SSL e, possivelmente, mTLS.
• TLS mútuo (mTLS) – A prática de exigir autenticação (por meio de certificado SSL/TLS) tanto para o cliente quanto para o host. O uso de mTLS também protege a confidencialidade e a integridade dos dados transmitidos entre o cliente e o host. O mTLS pode ser implementado até o nível de pod do Kubernetes, entre dois serviços no mesmo cluster. Para uma excelente introdução a SSL/TLS e mTLS, consulte O que é mTLS? no F5 Labs.
• Logon único (SSO) – As tecnologias de SSO (incluindo SAML, OAuth e OIDC) facilitam o gerenciamento da autenticação e da autorização.
  • Autenticação simplificada – O SSO elimina a necessidade de o usuário ter um token de ID exclusivo para cada recurso ou função.
  • Autorização padronizada – O SSO facilita a definição dos direitos de acesso dos usuários com base no cargo, no departamento e no nível de senioridade, eliminando a necessidade de configurar permissões individualmente para cada usuário.
• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – Um protocolo para estabelecer conexões autenticadas e criptografadas entre computadores em rede. Os certificados SSL/TLS autenticam a identidade de um site e estabelecem uma conexão criptografada. Embora o protocolo SSL tenha sido descontinuado em 1999 e substituído pelo protocolo TLS, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL/TLS” – para manter a consistência, usaremos SSL/TLS no restante deste artigo.
• Firewall de aplicações web (WAF) – Um proxy reverso que detecta e bloqueia ataques sofisticados contra aplicativos e APIs (incluindo o OWASP Top 10 e outras ameaças avançadas), permitindo a passagem de tráfego “seguro”. Os WAFs protegem contra ataques que tentam causar danos ao alvo por meio do roubo de dados confidenciais ou do sequestro do sistema. Alguns fornecedores reúnem a proteção WAF e contra DoS na mesma ferramenta, enquanto outros oferecem ferramentas separadas para WAF e DoS.
• Confiança zero – Um conceito de segurança frequentemente usado em organizações com requisitos de segurança mais rigorosos, mas relevante para todos, segundo o qual os dados devem ser protegidos em todas as etapas de armazenamento e transmissão. Isso significa que a organização decidiu não “confiar” por padrão em nenhum usuário ou dispositivo, exigindo, em vez disso, que todo o tráfego seja rigorosamente verificado. Uma arquitetura de confiança zero geralmente inclui uma combinação de autenticação, autorização e mTLS, com alta probabilidade de a organização implementar E2EE.

Caso de uso: corrija CVEs rapidamente para evitar ataques cibernéticos

Solução: Use ferramentas com notificações de patches oportunas e proativas

De acordo com um estudo do Ponemon Institute, em 2019, houve um “período de carência” médio de 43 dias entre o lançamento de uma correção para uma vulnerabilidade crítica ou de alta prioridade e o momento em que as organizações começaram a detectar ataques que tentavam explorar essa vulnerabilidade. Na F5 NGINX, observamos que esse intervalo diminuiu significativamente nos anos seguintes (chegando até mesmo ao dia zero no caso do Apple iOS 15, em 2021), por isso recomendamos aplicar as correções o mais rápido possível. Mas e se as correções para suas ferramentas de gerenciamento de tráfego só estiverem disponíveis semanas, ou até meses, após o anúncio de uma CVE?

Ferramentas desenvolvidas e mantidas por colaboradores da comunidade (em vez de uma equipe de engenharia dedicada) podem ficar semanas ou meses atrasadas em relação aos anúncios de CVEs, o que torna improvável que as organizações consigam aplicar as correções dentro desse período de 43 dias. Em um caso, o OpenResty levou quatro meses para aplicar uma correção de segurança relacionada ao NGINX. Isso deixou todos os usuários de um controlador Ingress baseado no OpenResty vulneráveis por pelo menos quatro meses, mas, na prática, geralmente há um atraso adicional até que as correções sejam disponibilizadas para softwares que dependem de um projeto de código aberto.

Para obter a correção mais rápida de CVEs, procure duas características ao selecionar ferramentas de gerenciamento de tráfego:

• Uma equipe de engenharia dedicada – Quando o desenvolvimento da ferramenta é gerenciado por uma equipe de engenharia, em vez de voluntários da comunidade, você sabe que há um grupo de pessoas dedicado à integridade da ferramenta e que pode priorizar o lançamento de uma correção o mais rápido possível.
• Uma base de código integrada – Sem dependências externas (como discutimos em relação ao OpenResty), as correções podem ser disponibilizadas em apenas um sprint ágil.

Para saber mais sobre a aplicação de patches para CVEs, leia Como mitigar vulnerabilidades de segurança de forma rápida e fácil com o NGINX Plus.

Caso de uso: interrompa ataques do OWASP Top 10 e de DoS

Solução: Implemente uma proteção flexível contra WAF e DoS, compatível com Kubernetes

A escolha da proteção certa contra WAF e DoS para aplicações Kubernetes depende de dois fatores (além dos recursos):

• Flexibilidade – Há cenários em que é melhor implantar ferramentas dentro do Kubernetes. Por isso, é importante contar com ferramentas independentes de infraestrutura, que possam ser executadas dentro ou fora do Kubernetes. Usar a mesma ferramenta em todas as suas implantações permite reutilizar políticas e reduz a curva de aprendizado das suas equipes de SecOps.
• Uso de recursos – As melhores ferramentas para Kubernetes têm baixo consumo de recursos, o que permite um uso adequado desses recursos com impacto mínimo na taxa de transferência, nas solicitações por segundo e na latência. Como as equipes de DevOps muitas vezes resistem às ferramentas de segurança por acreditarem que elas deixam os aplicativos mais lentos, escolher uma ferramenta de alto desempenho e baixo consumo de recursos pode aumentar a probabilidade de adoção.

Embora uma ferramenta que consolide a proteção contra WAF e DoS possa parecer mais eficiente, é provável que ela apresente problemas tanto em relação ao uso da CPU (devido a uma maior utilização de recursos) quanto à flexibilidade. Você é obrigado a implantar as proteções WAF e contra DoS em conjunto, mesmo quando não precisa de ambas. No fim das contas, esses dois problemas podem aumentar o custo total de propriedade das suas implantações do Kubernetes e, ao mesmo tempo, gerar restrições orçamentárias para outras ferramentas e serviços essenciais.

Depois de escolher as ferramentas de segurança certas para sua organização, é hora de decidir onde implantá-las. Normalmente, os serviços de aplicativos podem ser implantados em quatro locais para proteger aplicações Kubernetes:

• Na porta de entrada (em um balanceador de carga externo, como o F5 NGINX Plus ou o F5 BIG‑IP) – Ideal para uma proteção global de “baixa granularidade”, pois permite aplicar políticas globais a vários clusters
• Na borda (em um controlador de Ingress como o F5 NGINX Ingress Controller) – Ideal para fornecer proteção “granular” padronizada em um único cluster
• No serviço (em um balanceador de carga leve, como o NGINX Plus) – Pode ser uma abordagem necessária quando há um pequeno número de serviços em um cluster que compartilham a necessidade de políticas específicas
• No pod (como parte da aplicação) – Uma abordagem altamente personalizada que pode ser usada quando a política é específica para a aplicação

Então, entre as quatro opções, qual é a melhor? Bem... depende!

Onde implantar um WAF

Primeiro, analisaremos as opções de implantação de um WAF, pois essa costuma ser uma escolha que exige uma avaliação mais cuidadosa.

• Porta de entrada e borda – Se a sua organização prefere uma estratégia de segurança de “defesa em profundidade”, recomendamos implantar um WAF tanto no balanceador de carga externo quanto no controlador de Ingress para proporcionar um equilíbrio eficiente entre proteções globais e personalizadas.
• Ponto de entrada ou borda – Na ausência de uma estratégia de “defesa em profundidade”, é aceitável usar um único local, e o local de implantação depende de quem é o responsável. Quando uma equipe tradicional de NetOps é responsável pela segurança, ela pode se sentir mais à vontade para gerenciá-la em um proxy tradicional (o balanceador de carga externo). No entanto, as equipes de DevSecOps familiarizadas com o Kubernetes (e que preferem manter a configuração de segurança próxima às configurações do cluster) podem optar por implantar um WAF no nível de ingresso.
• Por serviço ou pod – Se suas equipes tiverem requisitos específicos para seus serviços ou aplicativos, elas poderão implantar WAFs adicionais conforme a necessidade. Mas atenção: esses locais implicam custos mais altos. Além de aumentar o tempo de desenvolvimento e o orçamento de nuvem, essa escolha também pode elevar os custos operacionais relacionados à solução de problemas – por exemplo, ao tentar determinar: “Qual dos nossos WAFs está bloqueando o tráfego sem querer?”

Onde implantar a proteção contra DoS

A proteção contra ataques de DoS é mais simples, pois só é necessária em um local – seja na porta de entrada ou no controlador de Ingress. Se você implantar um WAF tanto na porta de entrada quanto na borda, recomendamos implantar a proteção contra DoS à frente do WAF da porta de entrada, pois ele é o mais abrangente. Dessa forma, o tráfego indesejado pode ser reduzido antes de chegar ao WAF, permitindo um uso mais eficiente dos recursos computacionais.

Para saber mais sobre cada um desses cenários de implantação, leia Implantação de serviços de aplicativos no Kubernetes, parte 2.

Caso de uso: transfira a autenticação e a autorização dos aplicativos

Solução: Centralize a autenticação e a autorização no ponto de entrada

Um requisito não funcional comum incorporado a aplicativos e serviços é a autenticação e a autorização. Em pequena escala, essa prática acrescenta um nível de complexidade gerenciável, o que é aceitável quando o aplicativo não exige atualizações frequentes. No entanto, com ciclos de lançamento mais rápidos e em maior escala, integrar autenticação e autorização aos aplicativos torna-se inviável. Garantir que cada aplicativo mantenha os protocolos de acesso adequados pode desviar a atenção da lógica de negócios do aplicativo ou, pior, ser negligenciado e resultar em um vazamento de informações. Embora o uso de tecnologias de SSO possa aumentar a segurança ao substituir nomes de usuário e senhas separados por um único conjunto de credenciais, os desenvolvedores ainda precisam incluir código nos aplicativos para permitir a integração com o sistema de SSO.

Há uma maneira melhor: delegar a autenticação e a autorização a um controlador Ingress.

Como o controlador de Ingress já inspeciona todo o tráfego que entra no cluster e o encaminha para os serviços apropriados, ele é uma opção eficiente para centralizar a autenticação e a autorização. Isso elimina a necessidade de os desenvolvedores criarem, manterem e replicarem essa lógica no código da aplicação; em vez disso, eles podem aproveitar rapidamente as tecnologias de SSO na camada de ingresso usando a API nativa do Kubernetes.

Para saber mais sobre esse assunto, leia Implementação da autenticação OpenID Connect para Kubernetes com o Okta e o NGINX Ingress Controller.

Caso de uso: configure o autoatendimento com Guardrails

Solução: Implemente o controle de acesso baseado em funções (RBAC)

O Kubernetes usa o RBAC para controlar os recursos e as operações disponíveis para diferentes tipos de usuários. Essa é uma medida de segurança importante, pois permite que um administrador ou superusuário determine como usuários ou grupos de usuários podem interagir com qualquer objeto do Kubernetes ou namespace específico no cluster.

Embora o RBAC do Kubernetes esteja habilitado por padrão, você precisa garantir que suas ferramentas de gerenciamento de tráfego do Kubernetes também sejam compatíveis com RBAC e estejam alinhadas às necessidades de segurança da sua organização. Com o RBAC implementado, os usuários têm acesso controlado às funcionalidades necessárias para realizar seu trabalho sem precisar esperar pelo atendimento de um chamado. No entanto, sem o RBAC configurado, os usuários podem obter permissões desnecessárias ou às quais não têm direito, o que pode gerar vulnerabilidades caso essas permissões sejam usadas indevidamente.

Um controlador de Ingress é um excelente exemplo de ferramenta que pode atender a várias pessoas e equipes quando configurado com RBAC. Quando o controlador de Ingress permite um gerenciamento de acesso granular — até mesmo no nível de um único namespace —, você pode usar o RBAC para viabilizar o uso eficiente dos recursos por meio da multilocação.

Por exemplo, várias equipes podem usar o controlador Ingress da seguinte forma:

• Equipe de NetOps – Configura o ponto de entrada externo da aplicação (como o nome do host e os certificados TLS) e delega as políticas de controle de tráfego a várias equipes
• Equipe de DevOps A – Provisiona políticas de balanceamento de carga e roteamento TCP/UDP
• Equipe de DevOps B – Configura políticas de limitação de taxa para proteger os serviços contra solicitações excessivas
• Equipe de Identidade – Gerencia componentes de autenticação e autorização, além de configurar políticas de mTLS como parte de uma estratégia de criptografia de ponta a ponta
• Equipe de DevSecOps – Define políticas de WAF

Para saber como aproveitar o RBAC no NGINX Ingress Controller, assista a Implantações avançadas do Kubernetes com o NGINX Ingress Controller. A partir de 13:50, nossos especialistas explicam como aproveitar o RBAC e a alocação de recursos para garantir segurança, autoatendimento e multilocação.

Caso de uso: implementar criptografia de ponta a ponta

Solução: Use ferramentas de gerenciamento de tráfego

A criptografia de ponta a ponta (E2EE) está se tornando um requisito cada vez mais comum para organizações que lidam com informações confidenciais ou pessoais. Seja para dados financeiros ou mensagens em redes sociais, as expectativas dos consumidores em relação à privacidade, aliadas a regulamentações como o GDPR e a HIPAA, estão impulsionando a demanda por esse tipo de proteção. O primeiro passo para implementar a E2EE é projetar seus aplicativos de backend para aceitar tráfego SSL/TLS ou usar uma ferramenta que transfira o gerenciamento de SSL/TLS dos aplicativos para ela (a opção preferencial para separar as funções de segurança, melhorar o desempenho, gerenciar chaves etc.). Em seguida, configure suas ferramentas de gerenciamento de tráfego de acordo com a complexidade do seu ambiente.

Cenário mais comum: E2EE usando um controlador de Ingress

Quando você tem aplicações com apenas um endpoint (aplicações simples ou monolíticas que foram migradas para o Kubernetes usando a abordagem “lift and shift”) ou quando não há comunicação entre serviços, é possível usar um controlador Ingress para implementar E2EE no Kubernetes.

Etapa 1: Certifique-se de que seu controlador de Ingress permita apenas conexões SSL/TLS criptografadas usando certificados do lado do serviço ou mTLS, de preferência tanto para o tráfego de entrada quanto para o de saída.

Etapa 2: Altere a configuração padrão típica que exige que o controlador de Ingress descriptografe e criptografe novamente o tráfego antes de enviá-lo aos aplicativos. Isso pode ser feito de duas maneiras — o método escolhido depende do seu controlador de Ingress e dos seus requisitos:

• Se o seu controlador de Ingress for compatível com o passthrough de SSL/TLS, ele poderá rotear conexões criptografadas por SSL/TLS com base no cabeçalho Server Name Indication (SNI), sem descriptografá-las nem exigir acesso aos certificados ou às chaves SSL/TLS.
• Como alternativa, você pode configurar a terminação SSL/TLS, na qual o controlador de Ingress encerra o tráfego e, em seguida, o encaminha por proxy aos backends ou upstreams — seja em texto não criptografado ou recriptografando o tráfego com mTLS ou SSL/TLS no lado do serviço para seus serviços do Kubernetes.

Cenário menos comum: E2EE usando um controlador de Ingress e uma malha de serviços

Se houver comunicação entre serviços no seu cluster, você precisará implementar E2EE em dois planos: no tráfego de entrada e saída com o controlador de Ingress e no tráfego entre serviços com uma malha de serviços. Em E2EE, a função de uma malha de serviços é garantir que apenas serviços específicos possam se comunicar entre si e que façam isso de maneira segura. Ao configurar uma malha de serviços para E2EE, você precisa habilitar um ambiente de confiança zero por meio de dois fatores: mTLS entre os serviços (configurado para exigir um certificado) e controle de acesso ao tráfego entre os serviços (determinando quais serviços estão autorizados a se comunicar). O ideal é também implementar mTLS entre as aplicações (gerenciado por uma malha de serviços e pelo controlador de entrada e saída) para garantir uma verdadeira segurança E2EE em todo o cluster do Kubernetes.

Para saber mais sobre como criptografar dados que foram expostos durante a transmissão, leia A arquitetura mTLS no NGINX Service Mesh.

Caso de uso: garanta que os clientes estejam usando uma cifra forte com uma implementação confiável

Solução: Esteja em conformidade com os Padrões Federais de Processamento de Informações (FIPS)

No setor de software, FIPS geralmente se refere à publicação específica sobre criptografia, FIPS PUB 140-2 Requisitos de Segurança para Módulos Criptográficos, que é um esforço conjunto dos Estados Unidos e do Canadá. Ela padroniza os testes e a certificação de módulos criptográficos aceitos pelos órgãos federais de ambos os países para a proteção de informações confidenciais. “Mas espere!” você diz. “Não me importo com o FIPS porque não trabalho com órgãos governamentais norte-americanos.” Estar em conformidade com o FIPS pode ser uma decisão inteligente, independentemente do seu setor ou da sua localização geográfica, pois o FIPS também é, na prática, a referência criptográfica global.

Estar em conformidade com o FIPS não precisa ser difícil, mas exige que tanto o sistema operacional quanto as ferramentas relevantes de gerenciamento de tráfego possam operar no modo FIPS. Há um equívoco comum de que a conformidade com o FIPS é alcançada simplesmente executando o sistema operacional no modo FIPS. Mesmo com o sistema operacional nesse modo, ainda é possível que os clientes que se comunicam com o controlador Ingress não estejam usando uma cifra forte. Ao operar no modo FIPS, o sistema operacional e o controlador Ingress podem usar apenas um subconjunto das cifras SSL/TLS normalmente utilizadas.

A configuração do FIPS para suas implantações do Kubernetes é um processo de quatro etapas:

• Etapa 1: Configure seu sistema operacional para o modo FIPS
• Etapa 2: Verifique se o sistema operacional e o OpenSSL estão no modo FIPS
• Etapa 3: Instale o controlador Ingress
• Etapa 4: Verifique a conformidade com o FIPS 140-2 realizando uma verificação do status do FIPS

No exemplo abaixo, quando o modo FIPS está habilitado tanto para o sistema operacional quanto para a implementação do OpenSSL usada pelo NGINX Plus, todo o tráfego dos usuários finais de e para o NGINX Plus é descriptografado e criptografado usando um mecanismo criptográfico validado e habilitado para FIPS.

Saiba mais sobre FIPS em Como alcançar a conformidade com FIPS usando o NGINX Plus.

Torne o Kubernetes mais seguro com o NGINX

Se você está pronto para implementar alguns (ou todos) desses métodos de segurança, precisa garantir que suas ferramentas tenham os recursos e as funcionalidades adequados para atender aos seus casos de uso. A NGINX pode ajudar com nosso conjunto de ferramentas de gerenciamento de tráfego do Kubernetes prontas para ambientes de produção:

• NGINX Ingress Controller – Controlador Ingress para Kubernetes baseado no NGINX Plus, que oferece controle e modelagem avançados de tráfego, monitoramento e visibilidade, autenticação e SSO, além de atuar como gateway de API.
• F5 NGINX App Protect – Proteção abrangente para aplicativos e APIs modernos, desenvolvida com base nas tecnologias de segurança líderes de mercado da F5 e integrada ao NGINX Ingress Controller e ao NGINX Plus. Use uma abordagem modular para obter flexibilidade nos cenários de implantação e otimizar a utilização de recursos:
  • NGINX App Protect WAF – Um WAF robusto e leve que oferece proteção contra as 10 principais vulnerabilidades da OWASP e outras ameaças, em conformidade com o PCI DDS.
  • NGINX App Protect DoS – Detecção e mitigação comportamental de ataques DoS, com proteção consistente e adaptável em diferentes nuvens e arquiteturas.
• F5 NGINX Service Mesh – Malha de serviços leve, pronta para uso e fácil de usar para desenvolvedores, com o NGINX Plus como sidecar empresarial.

Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS e baixe o NGINX Service Mesh, que é sempre gratuito.

Sobre o autor

Jenn GileDiretor de Marketing de Produto, NGINX

Mais publicações de Jenn Gile