0
0
Não é tanto se as organizações estão usando o Kubernetes hoje, mas como estão expandindo seu uso. O uso de vários clusters, por exemplo, está aumentando e ultrapassando os limites organizacionais. O próprio Kubernetes está sendo reforçado para atender aos problemas de segurança resultantes . A versão mais recente, Kubernetes 1.26, adiciona recursos projetados para fortalecer a cadeia de confiança, entre outras atualizações de segurança. Na verdade, há uma série de projetos que as organizações devem observar – e potencialmente avaliar – para garantir que estão otimizando o uso do Kubernetes enquanto criam segurança, observabilidade, governança e conformidade mais fortes.
SPIFFE e SPIRE
A identidade para tudo é uma parte importante da proteção do seu ambiente Kubernetes, mas a identidade de ponta a ponta ainda é um problema não resolvido — especialmente em ambientes Kubernetes multicluster. Digamos que você tenha um serviço no Kubernetes e precise se autenticar em um serviço fora do cluster que está sendo executado na nuvem ou no local. Como você garante uma cadeia segura de identidade desde o lançamento do serviço até todas as coisas com as quais ele está se comunicando e se conectando — dentro e fora do cluster?O projeto SPIFFE é um conjunto de padrões de software livre para identificar com segurança sistemas de software em cargas de trabalho em ambientes heterogêneos e limites organizacionais. O Secure Production Identity Framework for Everyone (SPIFFE) define documentos de identidade criptográfica de curta duração, ou Shadow Virtual Intrusion Detection System ( SVIDS), que as cargas de trabalho podem usar para autenticar outras cargas de trabalho. O parceiro de identidade da SPIFFE é a SPIRE, o ambiente de tempo de execução SPIFFE. O SPIRE implementa a especificação SPIFFE, reforçando o atestado multifatorial para emitir identidades. Embora ainda haja trabalho a ser feito, os projetos SPIFFE e SPIRE – ambos incubados pela Cloud Native Computing Foundation (CNCF) – estão ajudando a definir as bases não apenas para identidade de ponta a ponta, mas também para confiança zero.
Sigstore
O velho ditado de que uma cadeia é tão forte quanto seu elo mais fraco não poderia ser mais verdadeiro do que quando se trata da cadeia de suprimentos de software . Conforme demonstrado pela onda de hacks da cadeia de suprimentos que vimos nos últimos anos – ataques que provavelmente aumentarão à medida que os riscos aumentam – é cada vez mais importante garantir que nada na cadeia de suprimentos seja adulterado. Uma das maneiras de fazer isso é assinar tudo — especialmente se você estiver fazendo tudo (ou mesmo a maioria das coisas) como código.Sigstore – sob os auspícios da Linux Foundation – destina-se a facilitar a assinatura criptográfica na cadeia de suprimentos. O Sigstore remove a carga de criptografia dos desenvolvedores, permitindo que eles usem um endereço de e-mail por meio do protocolo OpenID Connect (OIDC) como um identificador preexistente para assinar seu código. Estamos vendo organizações implementando o Sigstore de maneiras mais tradicionais, mas será interessante ver se elas adotam a assinatura baseada em OIDC (por meio da parte Fulcio do projeto Sigstore) e o registro de assinatura Rekor como uma maneira mais ágil de gerenciar assinaturas e atestado de assinaturas ou verificação de assinaturas. Também será interessante ver se o Sigstore é eventualmente implementado não apenas em novos produtos, mas também dentro da própria empresa.
Kyverno e OPA Gatekeeper
O Kyverno , que fornece gerenciamento de políticas nativas do Kubernetes, é um projeto a ser observado porque as organizações estão prestando mais atenção às políticas de admissão, principalmente à medida que a comunidade do Kubernetes se move em direção à admissão de segurança de pod. Existem apenas três perfis associados à admissão de segurança de pod nativo do Kubernetes — um modelo que é simples por design. Se você deseja mais complexidade, precisa usar algo como o Gatekeeper e Open Policy Agent (OPA). Algumas organizações acham o Kyverno mais fácil de usar com o Kubernetes. É baseado em YAML, portanto não requer o aprendizado de um novo idioma. No entanto, outras organizações investiram no aprendizado de Rego, a linguagem usada com o Open Policy Agent, pois o OPA é um mecanismo de política de uso geral que pode ser usado para automatizar políticas em toda a pilha. De fato, há uma variedade de mecanismos de política de código aberto disponíveis no momento. A verdadeira questão é se o cenário continuará pontilhado de mecanismos com graus variados de integração com o Kubernetes ou se um deles acabará se tornando o padrão de fato.
Projetos baseados em eBPF
O Kubernetes e as tecnologias com as quais ele trabalha dependem fortemente dos principais recursos do Linux. Um deles é o Extended Berkeley Packet Filter ( eBPF), que é cada vez mais usado em redes, segurança e auditoria, além de ferramentas de rastreamento e monitoramento. É importante ressaltar que, quando se trata de segurança de tempo de execução, o eBPF fornece observabilidade em um nível profundo. Você não pode proteger o que não pode ver, e o eBPF fornece o nível de observabilidade necessário para Kubernetes e plataformas de contêiner de uma forma mais consumível. O eBPF está sendo aproveitado por muitos projetos, incluindo Falco , uma ferramenta de segurança de tempo de execução do Kubernetes e Cilium, que fornece, protege e observa a conectividade de rede entre cargas de trabalho de contêiner. O maior indicador de quais projetos chegarão ao topo é como eles funcionam bem com o Kubernetes. Por exemplo, o Cilium é interessante porque é escrito em Go em vez de C, o que facilita a integração no Kubernetes.
Projetos de Rede Kubernetes
Estamos vendo cada vez mais organizações implantando vários clusters, resultando na necessidade de soluções que se comuniquem ou interajam entre os clusters. O Skupper é interessante porque permite que as organizações criem um tipo de rede virtual de aplicativos a partir de namespaces em um ou mais clusters Kube. É uma abordagem totalmente nova para gerenciar a comunicação entre clusters, eliminando a necessidade de VPNs ou regras especiais de firewall. A Gateway API , que vem da Kube SIG Network, está trabalhando para desenvolver e proteger a rede de serviços Kubernetes para torná-la mais extensível, com um conjunto de APIs que a levam além de L3 para L4 e L7. Gateway API é um projeto de código aberto gerenciado pela comunidade SIG Network .
Conclusão
À medida que as organizações expandem seu uso do Kubernetes, elas devem estar constantemente vigilantes sobre como equilibrar os ganhos de desempenho com segurança, governança e conformidade.
FONTE: DARK READING