Melhores práticas para a segurança e atualizações do cluster no Azure Kubernetes Service (AKS)
À medida que gere clusters no Azure Kubernetes Service (AKS), a carga de trabalho e a segurança dos dados são uma consideração fundamental. Quando executa clusters multi-inquilinos com isolamento lógico, precisa especialmente de proteger o acesso a recursos e cargas de trabalho. Minimize o risco de ataque ao aplicar as atualizações de segurança mais recentes do Kubernetes e do SO do nó.
Este artigo foca-se em como proteger o cluster do AKS. Saiba como:
- Utilize o Azure Active Directory e o controlo de acesso baseado em funções do Kubernetes (RBAC do Kubernetes) para proteger o acesso ao servidor de API.
- Proteger o acesso de contentor aos recursos do nó.
- Atualize um cluster do AKS para a versão mais recente do Kubernetes.
- Mantenha os nós atualizados e aplique automaticamente patches de segurança.
Também pode ler as melhores práticas para a gestão de imagens de contentor e para a segurança do pod.
Ativar a proteção contra ameaças
Orientação sobre melhores práticas
Pode ativar o Defender para Contentores para ajudar a proteger os contentores. O Defender para Contentores pode avaliar as configurações do cluster e fornecer recomendações de segurança, executar análises de vulnerabilidades e fornecer proteção e alertas em tempo real para nós e clusters do Kubernetes.
Proteger o acesso ao servidor de API e aos nós de cluster
Orientação sobre melhores práticas
Uma das formas mais importantes de proteger o cluster é proteger o acesso ao servidor da API do Kubernetes. Para controlar o acesso ao servidor de API, integre o RBAC do Kubernetes no Azure Active Directory (Azure AD). Com estes controlos, protege o AKS da mesma forma que protege o acesso às suas subscrições do Azure.
O servidor da API do Kubernetes fornece um único ponto de ligação para os pedidos efetuar ações num cluster. Para proteger e auditar o acesso ao servidor de API, limite o acesso e forneça os níveis de permissão mais baixos possíveis. Embora esta abordagem não seja exclusiva do Kubernetes, é especialmente importante quando isolou logicamente o cluster do AKS para utilização multi-inquilino.
Azure AD fornece uma solução de gestão de identidades pronta para empresas que se integra com clusters do AKS. Uma vez que o Kubernetes não fornece uma solução de gestão de identidades, pode ser difícil restringir o acesso granularmente ao servidor de API. Com Azure AD clusters integrados no AKS, utiliza as suas contas de utilizador e grupo existentes para autenticar utilizadores no servidor de API.
Com o RBAC do Kubernetes e Azure AD integração, pode proteger o servidor de API e fornecer as permissões mínimas necessárias para um conjunto de recursos no âmbito, como um único espaço de nomes. Pode conceder diferentes Azure AD utilizadores ou grupos diferentes funções do Kubernetes. Com permissões granulares, pode restringir o acesso ao servidor de API e fornecer um registo de auditoria claro das ações executadas.
A melhor prática recomendada é utilizar grupos para fornecer acesso a ficheiros e pastas em vez de identidades individuais. Por exemplo, utilize uma associação Azure AD grupo para vincular os utilizadores a funções do Kubernetes em vez de utilizadores individuais. À medida que a associação a um grupo de utilizadores muda, as respetivas permissões de acesso no cluster do AKS mudam em conformidade.
Entretanto, digamos que vincula o utilizador individual diretamente a uma função e as respetivas alterações à função de trabalho. Embora a Azure AD associações a grupos seja atualizada, as respetivas permissões no cluster do AKS não o fariam. Neste cenário, o utilizador acaba por ter mais permissões do que as necessárias.
Para obter mais informações sobre Azure AD integração, RBAC do Kubernetes e RBAC do Azure, veja Melhores práticas para autenticação e autorização no AKS.
Restringir o acesso à API de Metadados de Instância
Orientação sobre melhores práticas
Adicione uma política de rede em todos os espaços de nomes de utilizador para bloquear a saída do pod para o ponto final de metadados.
Nota
Para implementar a Política de Rede, inclua o atributo --network-policy azure ao criar o cluster do AKS. Utilize o seguinte comando para criar o cluster: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-instance-metadata
spec:
podSelector:
matchLabels: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.10.0.0/0#example
except:
- 169.254.169.254/32
Proteger o acesso de contentor aos recursos
Orientação sobre melhores práticas
Limitar o acesso às ações que os contentores podem executar. Forneça o menor número de permissões e evite a utilização de acesso de raiz ou escalamento privilegiado.
Da mesma forma que deve conceder aos utilizadores ou grupos os privilégios mínimos necessários, também deve limitar os contentores a ações e processos necessários. Para minimizar o risco de ataque, evite configurar aplicações e contentores que exijam privilégios escalados ou acesso raiz.
Por exemplo, defina allowPrivilegeEscalation: false no manifesto do pod. Estes contextos de segurança do pod do Kubernetes incorporados permitem-lhe definir permissões adicionais, como o utilizador ou grupo a executar como, ou as capacidades do Linux para expor. Para obter mais práticas recomendadas, veja Proteger o acesso de pods aos recursos.
Para um controlo ainda mais granular das ações de contentor, também pode utilizar funcionalidades de segurança incorporadas do Linux, como AppArmor e seccomp.
- Defina as funcionalidades de segurança do Linux ao nível do nó.
- Implementar funcionalidades através de um manifesto de pod.
As funcionalidades de segurança incorporadas do Linux só estão disponíveis em nós e pods do Linux.
Nota
Atualmente, os ambientes do Kubernetes não são completamente seguros para utilização hostil de vários inquilinos. Funcionalidades de segurança adicionais, como Microsoft Defender para ContentoresAppArmor, seccomp, Admissão de Segurança do Pod ou RBAC do Kubernetes para nós, bloquear explorações de forma eficiente.
Para uma verdadeira segurança ao executar cargas de trabalho multi-inquilino hostis, confie apenas num hipervisor. O domínio de segurança do Kubernetes torna-se todo o cluster e não um nó individual.
Para estes tipos de cargas de trabalho multi-inquilino hostis, deve utilizar clusters fisicamente isolados.
Proteção de Aplicações
Para limitar as ações de contentor, pode utilizar o módulo de segurança kernel appArmor Linux. O AppArmor está disponível como parte do SO do nó do AKS subjacente e está ativado por predefinição. Pode criar perfis AppArmor que restringem ações de leitura, escrita ou execução ou funções do sistema, como a montagem de sistemas de ficheiros. Os perfis AppArmor predefinidos restringem o acesso a várias /proc localizações e /sys fornecem um meio para isolar logicamente os contentores do nó subjacente. O AppArmor funciona para qualquer aplicação que seja executada no Linux e não apenas em pods do Kubernetes.
Para ver o AppArmor em ação, o exemplo seguinte cria um perfil que impede a escrita em ficheiros.
SSH para um nó do AKS.
Crie um ficheiro com o nome deny-write.profile.
Copie e cole o seguinte conteúdo:
#include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, }
Os perfis AppArmor são adicionados com o apparmor_parser comando .
Adicione o perfil a AppArmor.
Especifique o nome do perfil criado no passo anterior:
sudo apparmor_parser deny-write.profileSe o perfil for analisado corretamente e aplicado ao AppArmor, não verá nenhuma saída e será devolvido à linha de comandos.
A partir do seu computador local, crie um manifesto de pod com o nome aks-apparmor.yaml. Este manifesto:
- Define uma anotação para
container.apparmor.security.beta.kubernetes. - Faz referência ao perfil deny-write criado nos passos anteriores.
apiVersion: v1 kind: Pod metadata: name: hello-apparmor annotations: container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write spec: containers: - name: hello image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]- Define uma anotação para
Com o pod implementado, execute o seguinte comando e verifique se o pod hello-apparmor mostra um Estado em execução :
kubectl get pods NAME READY STATUS RESTARTS AGE aks-ssh 1/1 Running 0 4m2s hello-apparmor 0/1 Running 0 50s
Para obter mais informações sobre o AppArmor, consulte AppArmor profiles in Kubernetes (Perfis appArmor no Kubernetes).
Computação segura
Enquanto o AppArmor funciona para qualquer aplicação Linux, o seccomp (secure computing) funciona ao nível do processo. O Seccomp também é um módulo de segurança de kernel do Linux e é suportado nativamente pelo runtime do Docker utilizado pelos nós do AKS. Com o seccomp, pode limitar as chamadas do processo de contentor. Alinhe-se com a melhor prática de conceder ao contentor permissão mínima apenas para executar:
- Definir com filtra as ações a permitir ou negar.
- Anotar num manifesto YAML de pod para associar ao filtro seccomp.
Para ver o seccomp em ação, crie um filtro que impeça a alteração de permissões num ficheiro.
SSH para um nó do AKS.
Crie um filtro seccomp com o nome /var/lib/kubelet/seccomp/prevent-chmod.
Copie e cole o seguinte conteúdo:
{ "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "name": "chmod", "action": "SCMP_ACT_ERRNO" }, { "name": "fchmodat", "action": "SCMP_ACT_ERRNO" }, { "name": "chmodat", "action": "SCMP_ACT_ERRNO" } ] }Na versão 1.19 e posterior, tem de configurar o seguinte:
{ "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "names": ["chmod","fchmodat","chmodat"], "action": "SCMP_ACT_ERRNO" } ] }A partir do computador local, crie um manifesto de pod com o nome aks-seccomp.yaml e cole o seguinte conteúdo. Este manifesto:
- Define uma anotação para
seccomp.security.alpha.kubernetes.io. - Faz referência ao filtro prevent-chmod criado no passo anterior.
apiVersion: v1 kind: Pod metadata: name: chmod-prevented annotations: seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod spec: containers: - name: chmod image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: - "chmod" args: - "777" - /etc/hostname restartPolicy: NeverNa versão 1.19 e posterior, tem de configurar o seguinte:
apiVersion: v1 kind: Pod metadata: name: chmod-prevented spec: securityContext: seccompProfile: type: Localhost localhostProfile: prevent-chmod containers: - name: chmod image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: - "chmod" args: - "777" - /etc/hostname restartPolicy: Never- Define uma anotação para
Implemente o pod de exemplo com o comando kubectl apply :
kubectl apply -f ./aks-seccomp.yamlVeja o estado do pod com o comando kubectl get pods .
- O pod comunica um erro.
- O
chmodcomando é impedido de ser executado pelo filtro seccomp, conforme mostrado na seguinte saída de exemplo:
kubectl get pods NAME READY STATUS RESTARTS AGE chmod-prevented 0/1 Error 0 7s
Para obter mais informações sobre filtros disponíveis, veja Seccomp security profiles for Docker (Perfis de segurança seccomp para Docker).
Atualizar regularmente para a versão mais recente do Kubernetes
Orientação sobre melhores práticas
Para se manter atualizado sobre novas funcionalidades e correções de erros, atualize regularmente a versão do Kubernetes no cluster do AKS.
O Kubernetes lança novas funcionalidades a um ritmo mais rápido do que as plataformas de infraestrutura mais tradicionais. As atualizações do Kubernetes incluem:
- Novas funcionalidades
- Correções de erros ou segurança
Normalmente, as novas funcionalidades passam pelo estado alfa e beta antes de se tornarem estáveis. Uma vez estáveis, estão geralmente disponíveis e recomendados para utilização de produção. O novo ciclo de lançamento de funcionalidades do Kubernetes permite-lhe atualizar o Kubernetes sem encontrar regularmente alterações interruptivas ou ajustar as suas implementações e modelos.
O AKS suporta três versões secundárias do Kubernetes. Assim que for introduzida uma nova versão de patch secundária, a versão secundária mais antiga e as versões de patch suportadas serão descontinuadas. As atualizações secundárias do Kubernetes ocorrem de forma periódica. Para se manter no suporte, certifique-se de que tem um processo de governação para verificar se existem atualizações necessárias. Para obter mais informações, veja AKS de versões suportadas do Kubernetes.
Para verificar as versões disponíveis para o cluster, utilize o comando az aks get-upgrades , conforme mostrado no exemplo seguinte:
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Em seguida, pode atualizar o cluster do AKS com o comando az aks upgrade . O processo de atualização é seguro:
- Cordões e drena um nó de cada vez.
- Agenda pods nos nós restantes.
- Implementa um novo nó a executar as versões mais recentes do SO e do Kubernetes.
Importante
Teste novas versões secundárias num ambiente de teste de desenvolvimento e confirme que a carga de trabalho permanece em bom estado de funcionamento com a nova versão do Kubernetes.
O Kubernetes pode preterir as APIs (como na versão 1.16) em que as suas cargas de trabalho dependem. Ao colocar novas versões em produção, considere utilizar vários conjuntos de nós em versões separadas e atualizar conjuntos individuais um de cada vez para implementar progressivamente a atualização num cluster. Se executar vários clusters, atualize um cluster de cada vez para monitorizar progressivamente o impacto ou as alterações.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION
Para obter mais informações sobre atualizações no AKS, veja Versões suportadas do Kubernetes no AKS e Atualizar um cluster do AKS.
Processar atualizações de nós do Linux
Todas as noites, os nós do Linux no AKS obtêm patches de segurança através do respetivo canal de atualização de distribuição. Este comportamento é configurado automaticamente à medida que os nós são implementados num cluster do AKS. Para minimizar a interrupção e o potencial impacto nas cargas de trabalho em execução, os nós não são reiniciados automaticamente se uma atualização de kernel ou patch de segurança o exigir. Para obter mais informações sobre como lidar com reinícios de nós, veja Aplicar atualizações de segurança e kernel a nós no AKS.
Atualizações da imagem do nó
As atualizações automáticas aplicam atualizações ao SO do nó Linux, mas a imagem utilizada para criar nós para o cluster permanece inalterada. Se for adicionado um novo nó linux ao cluster, a imagem original é utilizada para criar o nó. Este novo nó receberá todas as atualizações de segurança e kernel disponíveis durante a verificação automática todas as noites, mas permanecerá inalterado até que todas as verificações e reinícios estejam concluídos. Pode utilizar a atualização da imagem do nó para procurar e atualizar imagens de nós utilizadas pelo cluster. Para obter mais informações sobre a atualização da imagem do nó, veja atualização da imagem do nó Azure Kubernetes Service (AKS).
Processar atualizações de nós do Windows Server
Para nós do Windows Server, execute regularmente uma operação de atualização de imagem de nó para isolar e drenar pods com segurança e implementar nós atualizados.