Ana Calin, engenheira de sistemas da Paybase, deu um relato de experiência no QCon Londres [slides do PDF] sobre como este provedor de serviços de pagamentos de ponta a ponta conseguiu atingir o nível 1 do PCI DSS (o mais alto) com mais de 50 microservices node.js em execução no Google Kubernetes Engine (GKE), usando o Terraform para provisionamento de infraestrutura e o Helm para implantação de serviços. Além de identificar e abordar algumas deficiências de segurança do Kubernetes, outro fator crucial foi desafiar o "status quo" dos requisitos do PCI DSS.
O PCI DSS é um padrão de segurança da informação que criado em 2004 e que as organizações que lidam com pagamentos com cartão de crédito devem respeitar. Os requisitos do PCI DSS [PDF] ainda não consideram explicitamente o impacto do Kubernetes ou da orquestração de contêineres em geral. Muitos deles giram em torno do conceito de uma "máquina servidor" como a unidade de computação básica e como os servidores devem ser protegidos e interconectados. Máquinas virtuais na nuvem podem ser mapeadas diretamente para esse conceito de "máquina servidor". Mas quando se fala em containers, pods e sua natureza transitória, a interpretação dos mesmos requisitos fica confusa.
Calin observou quantas organizações financeiras preferem pagar multas recorrentes do PCI DSS, em vez de investir na modernização de aplicativos legados para cumprir uma interpretação estrita dos requisitos do PCI DSS. No geral, em 2017, mais de 80% das organizações ainda não estão em conformidade com o padrão de segurança.
Calin mencionou o exemplo de um requisito do PCI DSS (#2.2.1) para que cada servidor ou máquina virtual desempenhe apenas uma função principal. Isso pode parecer simples se conseguirmos equiparar um "servidor" aqui com um pod Kubernetes. Mas se a interpretação é que um nó do Kubernetes é um "servidor", esse requisito seria claramente violado, já que um único nó poderia estar executando um número arbitrário de pods rodando várias funções simultaneamente.
Essa ambiguidade é agravada se o auditor de conformidade com o padrão de segurança não tiver um forte entendimento técnico do Kubernetes ou do GKE, como foi o caso do Paybase. Não deveria ser responsabilidade do provedor de pagamento educar os auditores, disse Calin. Ao perseverar que um "servidor" no jargão do PCI DSS é realmente uma unidade implantável (um pod) no Kubernetes e que as políticas de segurança de redes e pod do Kubernetes podem reforçar o isolamento entre serviços, Calin e seus colegas conseguiram demonstrar a conformidade.
Anteriormente, Calin e seus colegas haviam aprofundado a segurança do Kubernetes e GKE, incluindo um teste de penetração de infraestrutura interna, para garantir que o sistema fosse robusto o suficiente para lidar com as metas de regulamentação do PCI DSS, mesmo que os requisitos não fossem consistências do Kubernetes. Suas pesquisas e experimentos os levaram a definir um conjunto de diretrizes para um cluster seguro do GKE Kubernetes, como cada cluster tendo uma conta de serviço dedicada com permissões estritamente necessárias e escopos mínimos do mecanismo de computação. Configurar as políticas de rede e as políticas de segurança de pods do Kubernetes, bem como ativar o controle de acesso baseado em função (RBAC) é crítico, de acordo com Calin. E finalmente, sempre escanear imagens de contêiner que serão implantadas para vulnerabilidades (uma diretriz de segurança geral para contêineres).
Uma de suas descobertas em torno da segurança do GKE foi que Google Kubernetes vinha com alguns padrões inseguros, como o escopo do mecanismo de computação de leitura-gravação para novos clusters, o que significa que outros serviços do Google Cloud poderiam modificar o cluster. Além disso, a conta de serviço padrão associada tinha permissões excessivas, violando assim o princípio do menor privilégio. Por fim, os pontos de extremidade de metadados legados eram habilitados por padrão, o que significa que era possível obter segredos da API do Kubernetes a partir de qualquer pod em um cluster GKE.
Outros pontos fracos de segurança, incluíam o fato de que o Tiller, o servidor Helm que tinha permissões de leitura/gravação em todos os recursos em um cluster, não executava a autenticação por padrão e também vinha com o mTLS desativado. O acesso ao Tiller com configurações padrão permitiria que um hacker tivesse acesso total a um cluster, explicou Calin.