Melhores práticas para a segurança do pod em Azure Kubernetes Service (AKS)
À medida que desenvolve e executa aplicações em Azure Kubernetes Service (AKS), a segurança das suas cápsulas é 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 é o topo de mente 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 intruso possa tirar partido desses segredos para fins maliciosos. Não as adicione ao seu código nem as incorpore nas imagens do seu recipiente. Esta abordagem criaria um risco de exposição e limitaria a capacidade de rodar essas credenciais, uma vez que as imagens dos contentores terão de ser reconstruídas.
Este artigo de boas práticas centra-se em como proteger as cápsulas em AKS. Saiba como:
- Use o contexto de segurança do pod para limitar o acesso a processos e serviços ou escalada de privilégios
- Autenticar com outros recursos Azure utilizando identidades de carga de trabalho do Azure Ative Directory
- Solicitar e recuperar credenciais de um cofre digital como a Azure Key Vault
Também pode ler as melhores práticas para a segurança do cluster e para a gestão da imagem do contentor.
Acesso seguro dos recursos da cápsula
Orientação de boas práticas - Para funcionar como um utilizador ou grupo diferente e limitar o acesso aos processos e serviços do nó subjacente, defina as definições de contexto de segurança do pod. Atribua o menor número de privilégios necessários.
Para que as suas aplicações sejam executadas corretamente, as cápsulas devem funcionar como um utilizador ou grupo definido e não como raiz. O securityContext para uma cápsula ou recipiente permite definir definições como runAsUser ou fsGroup para assumir as permissões apropriadas. Apenas atribua as permissões necessárias ao utilizador ou grupo, e não utilize o contexto de segurança como meio para assumir permissões adicionais. As configurações de runAsUser, privilege e outras definições de capacidades Linux só estão disponíveis em nós e pods Linux.
Quando funciona como utilizador não-raiz, os contentores não podem ligar-se às portas privilegiadas abaixo de 1024. Neste cenário, os Serviços Kubernetes podem ser utilizados para disfarçar o facto de uma aplicação estar a funcionar numa determinada porta.
Um contexto de segurança do pod também pode definir capacidades ou permissões adicionais para aceder a processos e serviços. Podem ser definidas as seguintes definições de contexto de segurança comuns:
- permitir que a MelhorvilegeEscalation defina se o pod pode assumir privilégios de raiz . Desenhe as suas aplicações para que esta definição seja sempre definida como falsa.
- As capacidades do Linux permitem que o pod aceda aos processos subjacentes ao nó. Cuidado com a atribuição destas capacidades. Atribua o menor número de privilégios necessários. Para mais informações, consulte as capacidades do Linux.
- As etiquetas SELinux são 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 ficheiros. Mais uma vez, atribua o menor número de privilégios necessários. Para mais informações, consulte as opções SELinux em Kubernetes
O manifesto do seguinte exemplo do casulo YAML define as definições de contexto de segurança para definir:
- Pod funciona como iD 1000 do utilizador e parte do grupo ID 2000
- Não se pode escalar privilégios para usar
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 seu operador de cluster para determinar que definições de contexto de segurança necessita. Tente desenhar as suas aplicações para minimizar permissões adicionais e aceder ao pod requer. Existem funcionalidades de segurança adicionais para limitar o acesso usando o AppArmor e o seccomp (computação segura) que podem ser implementados pelos operadores de cluster. Para mais informações, consulte o acesso seguro dos contentores aos recursos.
Limitar a exposição à credencial
Orientação de boas práticas - Não defina credenciais no seu código de aplicação. Utilize identidades geridas para os recursos da Azure para permitir que o 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 geridas por pod destinam-se apenas a ser utilizadas apenas com cápsulas Linux e imagens de contentores.
Para limitar o risco de as credenciais serem expostas no seu código de 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 redistribuída. Uma melhor abordagem é dar aos pods a sua própria identidade e forma de se autenticarem, ou recuperarem automaticamente credenciais de um cofre digital.
Utilize uma identidade de carga de trabalho Azure AD (pré-visualização)
Uma identidade de carga de trabalho é uma identidade usada por uma aplicação em execução num casulo que pode autenticar-se contra outros serviços Azure que a suportam, como o Storage ou o SQL. Integra-se com as capacidades nativas de Kubernetes para federar com fornecedores de identidade externos. Neste modelo de segurança, o cluster AKS funciona como emitente simbólico, o Azure Ative Directory utiliza o OpenID Connect para descobrir chaves de assinatura pública e verificar a autenticidade da conta de serviço antes de trocá-la por um token Azure AD. A sua carga de trabalho pode trocar um token de conta de serviço projetado para o seu volume por um token Azure AD utilizando a biblioteca cliente da Identidade Azure utilizando o Azure SDK ou a Microsoft Authentication Library (MSAL).
Para obter mais informações sobre identidades de carga de trabalho, consulte configurar um cluster AKS para utilizar Azure AD identidades de carga de trabalho com as suas aplicações
Use a Key Vault Azure com o motorista CSI secrets Store
A utilização da identidade de carga de trabalho Azure AD permite a autenticação contra o apoio aos serviços Azure. Para os seus próprios serviços ou aplicações sem identidades geridas para recursos Azure, ainda pode autenticar usando credenciais ou chaves. Um cofre digital pode ser usado para armazenar estes conteúdos secretos.
Quando as aplicações precisam de uma credencial, comunicam com o cofre digital, recuperam os conteúdos secretos mais recentes e ligam-se ao serviço necessário. Azure Key Vault pode ser este cofre digital. O fluxo de trabalho simplificado para a recuperação de uma credencial do Azure Key Vault utilizando identidades geridas por cápsula é mostrado no seguinte diagrama:
Com Key Vault, armazena e gira regularmente segredos como credenciais, chaves de conta de armazenamento ou certificados. Pode integrar o Azure Key Vault com um cluster AKS utilizando o fornecedor Azure Key Vault para o Motorista CSI Secrets Store. O controlador CSI Secrets Store permite que o cluster AKS recupere de forma nativa conteúdos secretos a partir de Key Vault e os forneça de forma segura apenas à cápsula de solicitação. Trabalhe com o seu operador de cluster para implantar o motorista CSI Secrets Store em nós de trabalhadores AKS. Pode utilizar uma identidade de carga de trabalho Azure AD para solicitar o acesso a Key Vault e recuperar os conteúdos secretos necessários através do Motorista CSI Secrets Store.
Passos seguintes
Este artigo focou-se em como proteger as suas cápsulas. Para implementar algumas destas áreas, consulte os seguintes artigos: