Melhores práticas para a segurança de pods no Azure Kubernetes Service (AKS)
À medida que desenvolve e executa aplicações no Azure Kubernetes Service (AKS), a segurança dos pods é uma consideração fundamental. As suas aplicações devem ser concebidas para o princípio do menor número de privilégios necessários. Manter os dados privados seguros é uma das principais opções para os clientes. Não quer credenciais como cadeias de ligação de base de dados, chaves ou segredos e certificados expostos ao mundo exterior onde um atacante possa tirar partido desses segredos para fins maliciosos. Não os adicione ao seu código nem os incorpore nas imagens de contentor. Esta abordagem criaria um risco de exposição e limitaria a capacidade de rodar essas credenciais, uma vez que as imagens de contentor terão de ser reconstruídas.
Este artigo de melhores práticas centra-se em como proteger pods no AKS. Saiba como:
- Utilizar o contexto de segurança do pod para limitar o acesso a processos e serviços ou escalamento de privilégios
- Autenticar com outros recursos do Azure com identidades de carga de trabalho do Azure Active Directory
- Pedir e obter credenciais de um cofre digital, como o Azure Key Vault
Também pode ler as melhores práticas para a segurança do cluster e para a gestão de imagens de contentor.
Proteger o acesso de pods aos recursos
Orientação de melhores práticas – para executar como um utilizador ou grupo diferente e limitar o acesso aos serviços e processos de nós subjacentes, defina as definições de contexto de segurança do pod. Atribua o menor número de privilégios necessário.
Para que as suas aplicações funcionem corretamente, os pods devem ser executados como um utilizador ou grupo definido e não como raiz. O securityContext para um pod ou contentor permite-lhe definir definições como runAsUser ou fsGroup para assumir as permissões adequadas. Atribua apenas as permissões de utilizador ou grupo necessárias e não utilize o contexto de segurança como forma de assumir permissões adicionais. As definições runAsUser, escalamento de privilégios e outras funcionalidades do Linux só estão disponíveis em nós e pods do Linux.
Quando é executado como um utilizador não raiz, os contentores não podem vincular-se às portas privilegiadas em 1024. Neste cenário, o Kubernetes Services pode ser utilizado para disfarçar o facto de uma aplicação estar em execução numa porta específica.
Um contexto de segurança de pod também pode definir capacidades ou permissões adicionais para aceder a 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 . Crie as suas aplicações para que esta definição esteja sempre definida como falsa.
- As capacidades do Linux permitem que o pod aceda a processos de nós subjacentes. Tenha cuidado com a atribuição destas capacidades. Atribua o menor número de privilégios necessários. Para obter mais informações, veja Capacidades do Linux.
- As etiquetas SELinux são um módulo de segurança de kernel do Linux que lhe permite definir políticas de acesso para serviços, processos e acesso ao sistema de ficheiros. Mais uma vez, atribua o menor número de privilégios necessários. Para obter mais informações, veja Opções do SELinux no Kubernetes
O manifesto YAML do pod de exemplo seguinte define as definições de contexto de segurança para definir:
- O pod é executado como o ID de utilizador 1000 e parte do ID de grupo 2000
- Não é possível escalar privilégios para utilizar
root - Permite que as capacidades do Linux acedam às interfaces de rede e ao relógio em tempo real (hardware) do anfitrião
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 de cluster para determinar as definições de contexto de segurança de que precisa. Tente estruturar as suas aplicações para minimizar as permissões adicionais e aceder ao pod necessário. Existem funcionalidades de segurança adicionais para limitar o acesso através de AppArmor e seccomp (computação segura) que podem ser implementadas por operadores de cluster. Para obter mais informações, veja Proteger o acesso de contentor aos recursos.
Limitar a exposição de credenciais
Orientação de melhores práticas – não defina credenciais no código da aplicação. Utilize identidades geridas para recursos do Azure para permitir que o seu pod peça acesso a outros recursos. Um cofre digital, como o Azure Key Vault, também deve ser utilizado para armazenar e obter chaves digitais e credenciais. As identidades geridas por pods destinam-se apenas a ser utilizadas com pods do Linux e imagens de contentor.
Para limitar o risco de as credenciais serem expostas no código da aplicação, evite a utilização de credenciais fixas ou partilhadas. As credenciais ou chaves não devem ser incluídas diretamente no seu código. Se estas credenciais forem expostas, a aplicação tem de ser atualizada e reimplementada. Uma abordagem melhor é dar aos pods a sua própria identidade e forma de se autenticarem ou obterem automaticamente credenciais a partir de um cofre digital.
Utilizar uma identidade de carga de trabalho Azure AD
Uma identidade de carga de trabalho é uma identidade utilizada por uma aplicação em execução num pod que se pode autenticar noutros serviços do Azure que a suportam, como o Armazenamento ou o SQL. Integra-se com as capacidades nativas do Kubernetes para federar com fornecedores de identidade externos. Neste modelo de segurança, o cluster do AKS atua como emissor de tokens, o Azure Active Directory utiliza o OpenID Connect para detetar chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de o trocar por um token de Azure AD. A carga de trabalho pode trocar um token de conta de serviço projetado para o volume para um token de Azure AD com a biblioteca de cliente da Identidade do Azure com o SDK do Azure ou a Biblioteca de Autenticação da Microsoft (MSAL).
Para obter mais informações sobre identidades de cargas de trabalho, veja Configurar um cluster do AKS para utilizar Azure AD identidades de cargas de trabalho com as suas aplicações
Utilizar o Azure Key Vault com o Controlador CSI do Arquivo de Segredos
A utilização da identidade da carga de trabalho Azure AD permite a autenticação contra o suporte de serviços do Azure. Para os seus próprios serviços ou aplicações sem identidades geridas para recursos do Azure, ainda pode autenticar com credenciais ou chaves. Um cofre digital pode ser utilizado para armazenar estes conteúdos secretos.
Quando as aplicações precisam de uma credencial, comunicam com o cofre digital, obtêm os conteúdos secretos mais recentes e, em seguida, ligam-se ao serviço necessário. O Azure Key Vault pode ser este cofre digital. O fluxo de trabalho simplificado para obter uma credencial do Azure Key Vault com identidades geridas por pods é apresentado no seguinte diagrama:
Com Key Vault, armazena e roda regularmente segredos, como credenciais, chaves de conta de armazenamento ou certificados. Pode integrar o Azure Key Vault num cluster do AKS com o fornecedor de Key Vault do Azure para o Controlador CSI do Arquivo de Segredos. O controlador CSI do Arquivo de Segredos permite ao cluster do AKS obter nativamente conteúdos secretos de Key Vault e fornecê-los em segurança apenas ao pod requerente. Trabalhe com o operador de cluster para implementar o Controlador CSI do Arquivo de Segredos em nós de trabalho do AKS. Pode utilizar uma identidade de carga de trabalho Azure AD para pedir acesso ao Key Vault e obter os conteúdos secretos necessários através do Controlador CSI do Arquivo de Segredos.
Passos seguintes
Este artigo centrou-se em como proteger os seus pods. Para implementar algumas destas áreas, veja os seguintes artigos: