Práticas recomendadas de segurança do pod no Serviço de Kubernetes do Azure (AKS)
Ao desenvolver e executar aplicativos no serviço de Kubernetes do Azure (AKS), a segurança de seus pods é uma consideração importante. Os aplicativos devem ser criados para a entidade de segurança do número mínimo de privilégios necessários. Manter os dados privados seguros é prioritário para clientes. Você não quer que as credenciais como cadeias de caracteres de conexão de banco de dados, chaves ou segredos e certificados expostos ao mundo externo, onde um ataque poderia tirar proveito desses segredos para fins mal-intencionados. Não os adicione ao seu código ou insira-os em suas imagens de contêiner. Essa abordagem criaria um risco de exposição e limitaria a capacidade de girar as credenciais uma vez que as imagens de contêiner precisam ser recriadas.
Este artigo sobre melhores práticas se concentra em como proteger os pods no AKS. Você aprenderá como:
- Usar o contexto de segurança do pod para limitar o acesso a serviços e processos ou elevação de privilégios
- Autenticar com outros recursos do Azure usando a ID de Carga de Trabalho do Microsoft Entra
- Solicitar e recuperar as credenciais de um cofre digital, como o Azure Key Vault
Você também pode ler as melhores práticas para segurança do cluster e para gerenciamento da imagem de contêiner.
Proteger o acesso de pod para recursos
Diretrizes de práticas recomendadas - executar como usuário ou grupo diferente e limitar o acesso para os processos de nó e serviços subjacentes, definir as configurações do 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 grupo ou usuário definido e não como raiz. O securityContext para um pod ou contêiner permite que você defina configurações, como runAsUser ou fsGroup para presumir as permissões apropriadas. Somente atribua as permissões de usuário ou grupo necessárias e não use o contexto de segurança como um meio para admitir permissões adicionais. O runAsUser, a elevação de privilégio e outras configurações de recursos do Linux estão disponíveis apenas em nós e pods do Linux.
Ao executar como usuário não raiz, os contêineres não poderão associar às portas privilegiadas em 1024. Nesse cenário, os Serviços de Kubernetes podem ser usados para distinguir o fato de que um aplicativo é executado em uma porta específica.
Um contexto de segurança de pod também pode definir permissões para acessar os processos e serviços ou recursos adicionais. As seguintes definições de contexto de segurança comuns podem ser definidas:
- allowPrivilegeEscalation define se o pod pode assumir privilégios raiz. Projete seus aplicativos de forma que essa configuração seja sempre definida como false.
- Os recursos do Linux permitem que o pod acesse os processos de nó subjacente. Tome cuidado com a atribuição a esses recursos. Atribua o menor número de privilégios necessários. Para obter mais informações, consulte Recursos do Linux.
- Rótulos do SELinux é um módulo de segurança de kernel do Linux que permite que você defina políticas de acesso para serviços, processos e acesso a sistema de arquivos. Novamente, atribua o menor número de privilégios necessários. Para obter mais informações, consulte Opções SELinux no Kubernetes
O manifesto YAML do pod de exemplo a seguir define as configurações de contexto de segurança a definir:
- O pod é executado com a ID de usuário 1000 e faz parte da ID do grupo 2000
- Não é possível escalonar os privilégios para usar
root - Permite que os recursos do Linux acessem as 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 seu operador de cluster para determinar quais configurações de contexto de segurança são necessárias. Tente projetar seus aplicativos para minimizar o acesso que requer o pod e as permissões do pod. Há recursos de segurança adicionais para limitar o acesso usando o AppArmor e seccomp (computação segura) que pode ser implementado por operadores do cluster. Para obter mais informações, consulte Proteger acesso do contêiner para recursos.
Exposição de credencial de limite
Diretrizes de práticas recomendadas - não defina as credenciais no código do aplicativo. Use identidades gerenciadas para recursos do Azure para permitir sua solicitação de acesso de pod para outros recursos. Um cofre digital, como o Azure Key Vault, também deve ser usado para armazenar e recuperar as credenciais e chaves digitais. As identidades gerenciadas por pod devem ser usadas somente com pods e imagens de contêiner do Linux.
Para limitar o risco de credenciais que estão sendo expostas no código do aplicativo, evite o uso de credenciais compartilhadas ou fixas. As credenciais ou chaves não devem ser incluídas diretamente em seu código. Se essas credenciais são expostas, o aplicativo precisa ser atualizado e reimplantado. Uma abordagem melhor é dar aos pods sua própria identidade e maneira de se autenticar ou recuperar credenciais automaticamente de um cofre digital.
Usar a ID de Carga de Trabalho do Microsoft Entra
Uma identidade de carga de trabalho é uma identidade usada por um aplicativo executando em um pod que pode se autenticar em outros serviços do Azure que dão suporte a ela, como armazenamento ou SQL. Ele se integra aos recursos nativos do Kubernetes para federar com provedores de identidade externos. Nesse modelo de segurança, o cluster do AKS atua como emissor de token, o Microsoft Entra ID usa OpenID Connect para descobrir chaves de assinatura pública e verificar a autenticidade do token da conta de serviço antes de trocá-lo por um token do Microsoft Entra. A carga de trabalho pode trocar um token de conta de serviço projetado para o seu volume por um token do Microsoft Entra usando a biblioteca de clientes 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 do AKS para usar a ID de Carga de Trabalho do Microsoft Entra com seus aplicativos
Use o Azure Key Vault com o driver do CSI de armazenamento de segredos
O uso da ID de Carga de Trabalho do Microsoft Entra habilita a autenticação no suporte aos serviços do Azure. 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 de segredos.
Quando os aplicativos precisam de uma credencial, eles se comunicam com o cofre digital, recuperam o conteúdo secreto mais recente e, em seguida, conectam-se ao serviço necessário. O Azure Key Vault pode ser este cofre digital. O fluxo de trabalho simplificado para recuperar uma credencial de Cofre de Chaves do Azure usando identidades gerenciadas de pod é mostrado no diagrama a seguir:
Com o Azure Key Vault, você pode armazenar e regularmente girar segredos, como certificados, chaves de conta de armazenamento ou as credenciais. Você pode integrar o Azure Key Vault com um cluster AKS usando o Provedor do Azure Key Vault para o driver do CSI de armazenamento de segredos. O driver do CSI de armazenamento de segredos permite que o cluster AKS recupere nativamente o conteúdo secreto do cofre de chaves e os forneça com segurança apenas para o pod solicitante. Trabalhe com seu operador de cluster para implantar o driver do CSI de armazenamento de segredos nos nós de trabalho do AKS. É possível usar uma D de Carga de Trabalho do Microsoft Entra para solicitar acesso ao Key Vault e recuperar o conteúdo secreto necessário por meio do Driver do CSI do Armazenamento de Segredos.
Próximas etapas
Este artigo se concentrou em como proteger seus pods. Para implementar algumas dessas áreas, confira os seguintes artigos: