Práticas recomendadas para gerenciar Secrets no Kubernetes

Escrito por

16 de novembro de 2022

0 minutos de leitura

O Kubernetes usa objetos secretos, chamados Secrets, para armazenar tokens OAuth, chaves Secure Shell (SSH), senhas e outros dados confidenciais. Os Kubernetes Secrets permitem manter dados confidenciais separados do código da aplicação, criando-os separadamente dos pods. Essa separação, junto com uma configuração bem definida de controle de acesso baseado em função (RBAC), reduz as chances de um Secret ser exposto — e possivelmente explorado — durante a interação com os pods, aumentando a segurança.

Embora os Kubernetes Secrets ajudem a evitar a exposição acidental de dados, talvez não protejam os dados do cluster contra ataques cibernéticos maliciosos. Por exemplo, um usuário não autorizado com permissão para acessar o cluster etcd pode acessar todos os nossos Kubernetes Secrets. Por isso, precisamos gerenciá-los com cuidado para garantir sua segurança.

Neste artigo, vamos explorar as práticas recomendadas para gerenciar Secrets no Kubernetes. Confira nosso artigo sobre segurança do Kubernetes para conhecer outros riscos e práticas recomendadas.

Como funcionam os Kubernetes Secrets

Os Kubernetes Secrets permitem que os usuários armazenem dados em um objeto Secret, que pode ser acessado ou modificado por clientes do Kubernetes. Um Secret é um par de chave e valor que inclui um ID de Secret e informações de autenticação. O Kubelet usa o ID de Secret para identificar as credenciais que devem ser fornecidas a um contêiner de aplicação ao criar um pod.

O Kubelet é executado em cada nó de um cluster e gerencia pods e seus contêineres. Os pods só podem acessar Secrets quando eles fazem parte explicitamente de um volume montado ou no momento em que o kubelet baixa uma imagem para uso em um pod.

O servidor da API do Kubernetes armazena os Kubernetes Secrets. Eles só podem ser acessados por usuários específicos com permissão para acessar o servidor da API do Kubernetes. Como o servidor da API do Kubernetes é um ponto único de falha para nossa aplicação, precisamos manter nossos dados protegidos.

Os Kubernetes Secrets:

Oferecem uma forma segura de compartilhar dados de configuração entre um controlador e seus workers, como entre um kubelet e um pod
Oferecem uma alternativa para armazenar dados confidenciais no cluster do Kubernetes, como credenciais de acesso a aplicações externas
Oferecem uma forma prática de criar novos recursos no cluster do Kubernetes, como novos deployments ou namespaces

Práticas recomendadas para Kubernetes Secrets

Secrets, como chaves, senhas, tokens e outros valores de configuração, precisam ser armazenados corretamente. Se nosso cluster do Kubernetes for comprometido, os Secrets ainda devem permanecer seguros. Um invasor não deve conseguir explorar Secrets para comprometer dados confidenciais, criar uma botnet ou controlar servidores de comando e controle (C2).

Confira algumas técnicas para manter os Kubernetes Secrets seguros:

Ative a criptografia de dados em repouso
Configure regras de RBAC
Criptografe os dados do etcd
Use um repositório centralizado de Secrets para facilitar o gerenciamento

Ative a criptografia de dados em repouso

Os dados dos Kubernetes Secrets são codificados no formato base64 e armazenados como texto simples no etcd. O etcd é um armazenamento de chave-valor usado para guardar o estado do cluster do Kubernetes e os dados de configuração. Armazenar Secrets como texto simples no etcd é arriscado, pois eles podem ser facilmente comprometidos por invasores e usados para acessar sistemas.

O banco de dados etcd não é criptografado por padrão. Por isso, precisamos criptografar os dados dos Secrets em repouso para proteger as informações confidenciais contra o acesso de invasores. Um invasor com acesso ao sistema de arquivos pode ler os Secrets armazenados nos arquivos.

Além disso, o Kubernetes oferece um recurso de criptografia em repouso que permite usar a API do Kubernetes para criptografar Secrets antes de armazená-los no etcd. Também podemos usar provedores de criptografia, como KMSConfiguration, IdentityConfiguration, SecretboxConfiguration e AESConfiguration, para proteger nossos Secrets em repouso.

Um cluster do Kubernetes tem vários nós, cada um com credenciais exclusivas para operações de criptografia e descriptografia. O objeto EncryptionConfiguration especifica o material de chave para essas operações em cada nó. A configuração desses provedores de criptografia fica no objeto EncryptionConfiguration, que permite criptografar Secrets localmente com uma chave gerenciada localmente.

Configure regras de RBAC

Criptografar os Kubernetes Secrets em repouso é apenas uma parte do que é necessário para mantê-los seguros. Também devemos controlar o acesso aos Secrets usando regras de RBAC do Kubernetes. A política de segurança que autoriza o acesso a Secrets pode ser baseada em tarefas, tempo ou funções.

Kubernetes Secrets e regras de RBAC funcionam em conjunto. Um dos principais motivos para a existência dos objetos Secret no Kubernetes é permitir um acesso RBAC diferente do que concederíamos a um ConfigMap.

Podemos usar o objeto ClusterRoles para definir as ações que um usuário pode realizar em um cluster e uma função para definir as ações permitidas em um namespace. O RBAC restringe a criação, exclusão e modificação de Secrets a usuários específicos. Por exemplo, podemos definir uma política que proíba desenvolvedores de criar Secrets em determinado namespace, mas não nos demais.

A estrutura de RBAC integrada ao Kubernetes permite aplicar o princípio do menor privilégio (PoLP), restringindo o acesso de usuários ou programas apenas aos recursos ou informações necessários para realizar as tarefas atribuídas ou funcionar corretamente. Isso ajuda a garantir que somente contas e contêineres privilegiados tenham acesso aos Secrets. Se um invasor comprometer um componente, o PoLP ajuda a impedir que ele eleve suas permissões e comprometa outros componentes.

Criptografe os dados do etcd

Como basta ter permissão para acessar o cluster etcd para acessar os Secrets, precisamos proteger com rigor os dados confidenciais, com práticas como rotação automática de chaves, visibilidade sobre a idade das chaves e registros de auditoria. A melhor forma de fazer isso é impedir que esses dados fiquem disponíveis no etcd. O driver de armazenamento padrão do etcd é local, e as chaves de criptografia são armazenadas localmente no arquivo de configuração. Isso pode deixá-las vulneráveis a malware e outras ameaças maliciosas.

Uma forma de reforçar a segurança dos dados do etcd é criptografar os Secrets antes de armazená-los. Devemos usar um provedor de criptografia, como um serviço de gerenciamento de chaves (KMS), para armazenar nossas chaves e Secrets. Vale lembrar que a maioria dos provedores de Kubernetes gerenciados criptografa o armazenamento de Secrets do etcd por padrão quando um cluster é criado, ajudando a manter os dados do etcd seguros.

Outra medida de segurança é permitir que apenas o servidor da API acesse o etcd. Devemos permitir o uso dos clusters etcd somente aos nós que precisam acessá-los. Podemos conceder acesso ao etcd por meio do servidor da API do Kubernetes e limitar as permissões de leitura e gravação a usuários ou grupos específicos.

Use um repositório centralizado de Secrets para facilitar o gerenciamento

Os Kubernetes Secrets são essenciais para o funcionamento da nossa aplicação e podem ser armazenados em vários locais. Quando os armazenamos em muitos lugares, fica mais difícil protegê-los — principalmente quando precisamos gerenciá-los em vários clusters ou quando temos uma combinação de pares de chaves públicas e privadas. Sem um sistema centralizado de gerenciamento de Secrets, eles ficam espalhados por diferentes locais, aumentando a superfície de ataque para usuários não autorizados.

Gerenciar Secrets de forma centralizada oferece muitas vantagens, principalmente quando eles são usados em várias instâncias. Uma solução centralizada de gerenciamento oferece uma visão unificada do cenário de segurança do Kubernetes. Podemos gerenciar Secrets, controles de acesso e auditorias com facilidade, e um registro de auditoria centralizado ajuda a identificar eventos críticos de segurança.

Provedores terceirizados oferecem recursos mais avançados e seguros para gerenciar Kubernetes Secrets. Confira abaixo alguns serviços populares de gerenciamento de Secrets de terceiros.

AWS Secrets Manager

O AWS Secrets Manager oferece uma forma simples e segura de armazenar e alternar Secrets. Ele disponibiliza um console unificado para gerenciar todos os nossos recursos do Amazon Web Services (AWS). A ferramenta AWS Secrets Manager é integrada ao Kubernetes e permite armazenar nossos Secrets criptografados com segurança no Kubernetes. Assim, podemos usar a API do Kubernetes para acessá-los durante a execução, sem nos preocupar com a exposição no código.

Esse serviço de gerenciamento de Secrets permite recuperar, visualizar e gerenciar credenciais e Secrets da AWS em um único local seguro. Podemos usar o AWS Secrets Manager com outros serviços da AWS, como AWS Identity and Access Management (IAM), AWS Key Management Service (AWS KMS) e AWS Simple Storage Service (S3).

Azure Key Vault e Azure Kubernetes Service

O Microsoft Azure Key Vault é um gerenciador de Secrets que permite armazenar e usar chaves criptográficas. Podemos fazer backup e recuperar objetos de vault excluídos, registrar e monitorar Secrets e usar cofres de chaves para autenticar usuários.

Além disso, podemos usar o Azure Kubernetes Service (AKS) para autorização com Azure RBAC e Kubernetes RBAC. Também podemos usar o Azure RBAC para controlar o acesso a recursos por meio de atribuições de função. Ele também autoriza grupos e usuários, enquanto o Kubernetes RBAC integrado permite o uso de contas de serviço do Kubernetes.

HashiCorp Vault

O HashiCorp Vault é uma ferramenta de código aberto para armazenar e gerenciar Secrets e proteger dados confidenciais. Ela gerencia o acesso de usuários a dados confidenciais, permitindo alternar esses dados ou revogar o acesso a eles diante de uma ameaça à segurança.

Podemos usar o HashiCorp Vault para implementar várias medidas de segurança do Kubernetes, incluindo criptografia de dados, controle de acesso baseado em identidade e gerenciamento de Secrets. O HashiCorp Vault usa criptografia TSL e AES de 256 bits para proteger os dados em trânsito e em repouso, respectivamente.

Conclusão

Secrets autenticam usuários e serviços e controlam o acesso a recursos e a outros Secrets. Os Kubernetes Secrets permitem armazenar dados em um objeto Secret, que pode ser acessado ou modificado por clientes do Kubernetes. Como os Secrets contêm dados confidenciais, como tokens, chaves e senhas, é fundamental seguir as práticas recomendadas para mantê-los seguros.

Há várias formas de proteger nossos Secrets. Para começar, devemos ativar a criptografia em repouso. Criptografar Secrets em repouso aumenta sua segurança. No entanto, criptografar objetos Kubernetes Secret em repouso é apenas uma parte da proteção. Também devemos controlar o acesso aos Secrets com regras de RBAC. A estrutura de RBAC integrada ao Kubernetes permite restringir o acesso de usuários ou programas, disponibilizando apenas os recursos ou informações necessários. Também podemos recorrer a um serviço de gerenciamento de Secrets de terceiros, como os mencionados acima, para ajudar a manter nossos Secrets seguros.

Para gerenciar Secrets corretamente, tanto desenvolvedores quanto administradores de clusters do Kubernetes precisam monitorar de perto a segurança das informações confidenciais. Além de seguir as práticas recomendadas apresentadas aqui, confira o guia do Kubernetes para gerenciar Secrets — voltado a desenvolvedores e administradores de clusters — e mantenha seus Secrets protegidos.

Proteger credenciais e outros Secrets é apenas uma etapa para executar aplicações mais seguras: você precisa proteger todas as fases do ciclo de vida de desenvolvimento de software. Identifique e corrija possíveis vulnerabilidades no código que você escreve e nos projetos de código aberto que utiliza com Snyk Code e Snyk Open Source. Use também Snyk Container para começar com uma imagem base mais segura e identificar vulnerabilidades adicionais que possam surgir durante o processo de build. Por fim, verifique se o código implantado não contém falhas de segurança com Snyk IaC.

Proteja a infraestrutura desde a origem

A Snyk automatiza a segurança e a conformidade de IaC nos fluxos de trabalho e detecta recursos com configurações divergentes ou ausentes.

Agende uma demonstração ao vivo Comece grátis