Práticas recomendadas para segurança de pod no Serviço Kubernetes do Azure (AKS)
À medida que você desenvolve e executa aplicativos no Serviço Kubernetes do Azure (AKS), a segurança de seus pods é uma consideração fundamental. Seus aplicativos devem ser projetados para o princípio do menor número de privilégios necessários. Manter os dados privados seguros é a principal preocupação dos clientes. Você não quer credenciais como cadeias de conexão de banco de dados, chaves ou segredos e certificados expostos ao mundo exterior, onde um invasor pode tirar proveito desses segredos para fins mal-intencionados. Não os adicione ao seu código nem os incorpore em suas imagens de contêiner. Essa abordagem criaria um risco de exposição e limitaria a capacidade de girar essas credenciais, pois as imagens de contêiner precisarão ser reconstruídas.
Este artigo de práticas recomendadas se concentra em como proteger pods no AKS. Sabe como:
- Use o contexto de segurança do pod para limitar o acesso a processos e serviços ou o escalonamento de privilégios
- Autenticar com outros recursos do Azure usando a ID de Carga de Trabalho do Microsoft Entra
- Solicitar e recuperar credenciais de um cofre digital, como o Azure Key Vault
Você também pode ler as práticas recomendadas para segurança de cluster e gerenciamento de imagens de contêiner.
Acesso seguro do pod aos recursos
Orientação de práticas recomendadas - Para executar como um usuário ou grupo diferente e limitar o acesso aos processos e serviços do nó subjacente, defina as configurações de contexto de segurança do pod. Atribua o menor número de privilégios necessários.
Para que seus aplicativos sejam executados corretamente, os pods devem ser executados como um usuário ou grupo definido e não como root. O securityContext para um pod ou contêiner permite definir configurações como runAsUser ou fsGroup para assumir as permissões apropriadas. Atribua apenas as permissões de usuário ou grupo necessárias e não use o contexto de segurança como um meio de assumir permissões adicionais. As configurações runAsUser, escalonamento de privilégios e outros recursos do Linux só estão disponíveis em nós e pods do Linux.
Quando você é executado como um usuário não-raiz, os contêineres não podem se vincular às portas privilegiadas em 1024. Nesse cenário, os Serviços Kubernetes podem ser usados para disfarçar o fato de que um aplicativo está sendo executado em uma porta específica.
Um contexto de segurança de pod também pode definir recursos ou permissões adicionais para acessar processos e serviços. As seguintes definições comuns de contexto de segurança podem ser definidas:
- allowPrivilegeEscalation define se o pod pode assumir privilégios de raiz . Projete seus aplicativos para que essa configuração seja sempre definida como false.
- Os recursos do Linux permitem que o pod acesse os processos do nó subjacente. Tenha cuidado com a atribuição desses recursos. Atribua o menor número de privilégios necessários. Para obter mais informações, consulte Recursos do Linux.
- SELinux labels é um módulo de segurança do kernel Linux que permite definir políticas de acesso para serviços, processos e acesso ao sistema de arquivos. Novamente, atribua o menor número de privilégios necessários. Para obter mais informações, consulte Opções do SELinux no Kubernetes
O seguinte exemplo pod YAML manifest define configurações de contexto de segurança para definir:
- O Pod é executado como ID de usuário 1000 e parte do ID de grupo 2000
- Não é possível escalar privilégios para usar
root - Permite que os recursos do Linux acessem interfaces de rede e o relógio (hardware) em tempo real do host
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Trabalhe com o operador do cluster para determinar quais configurações de contexto de segurança você precisa. Tente projetar seus aplicativos para minimizar permissões adicionais e acessar o pod requer. Existem recursos de segurança adicionais para limitar o acesso usando AppArmor e seccomp (computação segura) que podem ser implementados por operadores de cluster. Para obter mais informações, consulte Proteger o acesso de contêiner aos recursos.
Limitar a exposição de credenciais
Orientação de práticas recomendadas - Não defina credenciais no código do aplicativo. Use identidades gerenciadas para recursos do Azure para permitir que seu pod solicite acesso a outros recursos. Um cofre digital, como o Azure Key Vault, também deve ser usado para armazenar e recuperar chaves e credenciais digitais. As identidades gerenciadas por pods destinam-se ao uso apenas com pods Linux e imagens de contêiner.
Para limitar o risco de as credenciais serem expostas no código do aplicativo, evite o uso de credenciais fixas ou compartilhadas. As credenciais ou chaves não devem ser incluídas diretamente no seu código. Se essas credenciais forem expostas, o aplicativo precisará ser atualizado e reimplantado. Uma abordagem melhor é dar aos pods sua própria identidade e maneira de se autenticar, ou recuperar automaticamente as credenciais de um cofre digital.
Usar uma ID de carga de trabalho do Microsoft Entra
Uma identidade de carga de trabalho é uma identidade usada por um aplicativo em execução em um pod que pode autenticar-se em relação a outros serviços do Azure que oferecem suporte a ela, como Armazenamento ou SQL. Ele se integra com os recursos nativos do Kubernetes para federar com provedores de identidade externos. Neste modelo de segurança, o cluster AKS atua como emissor de token, o Microsoft Entra ID usa o OpenID Connect para descobrir chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de trocá-lo por um token do Microsoft Entra. Sua carga de trabalho pode trocar um token de conta de serviço projetado para seu volume por um token do Microsoft Entra usando a biblioteca de cliente do Azure Identity usando o SDK do Azure ou a Biblioteca de Autenticação da Microsoft (MSAL).
Para obter mais informações sobre identidades de carga de trabalho, consulte Configurar um cluster AKS para usar o ID de carga de trabalho do Microsoft Entra com seus aplicativos
Usar o Azure Key Vault com o Driver CSI do Secrets Store
O uso da ID de Carga de Trabalho do Microsoft Entra habilita a autenticação em relação aos serviços do Azure com suporte. Para seus próprios serviços ou aplicativos sem identidades gerenciadas para recursos do Azure, você ainda pode autenticar usando credenciais ou chaves. Um cofre digital pode ser usado para armazenar esses conteúdos secretos.
Quando os aplicativos precisam de uma credencial, eles se comunicam com o cofre digital, recuperam o conteúdo secreto mais recente e se conectam ao serviço necessário. O Azure Key Vault pode ser este cofre digital. O fluxo de trabalho simplificado para recuperar uma credencial do Cofre de Chaves do Azure usando identidades gerenciadas por pod é mostrado no diagrama a seguir:
Com o Cofre de Chaves, você armazena e alterna regularmente segredos como credenciais, chaves de conta de armazenamento ou certificados. Você pode integrar o Azure Key Vault a um cluster AKS usando o provedor do Azure Key Vault para o Driver CSI do Secrets Store. O driver CSI do Secrets Store permite que o cluster AKS recupere nativamente conteúdos secretos do Cofre de Chaves e os forneça com segurança apenas para o pod solicitante. Trabalhe com o operador do cluster para implantar o driver CSI do Secrets Store nos nós de trabalho do AKS. Você pode usar uma ID de Carga de Trabalho do Microsoft Entra para solicitar acesso ao Cofre da Chave e recuperar o conteúdo secreto necessário por meio do Driver CSI do Repositório de Segredos.
Próximos passos
Este artigo focou-se em como proteger os seus pods. Para implementar algumas dessas áreas, consulte os seguintes artigos: