Proteger os clusters do Azure Kubernetes Service (AKS) com Azure Policy
Pode aplicar e impor políticas de segurança incorporadas nos clusters do Azure Kubernetes Service (AKS) com Azure Policy. Azure Policy ajuda a impor normas organizacionais e a avaliar a conformidade em escala. Depois de instalar o suplemento Azure Policy para o AKS, pode aplicar definições de políticas individuais ou grupos de definições de política denominados iniciativas (por vezes denominados conjuntos de políticas) ao cluster. Veja Azure Policy definições incorporadas do AKS para obter uma lista completa das definições de política e iniciativa do AKS.
Este artigo mostra-lhe como aplicar definições de política ao cluster e verificar se essas atribuições estão a ser impostas.
Pré-requisitos
- Este artigo pressupõe que tem um cluster do AKS existente. Se precisar de um cluster do AKS, pode criar um com a CLI do Azure, Azure PowerShell ou portal do Azure.
- Precisa do suplemento Azure Policy para o AKS instalado no cluster do AKS.
Atribuir uma definição ou iniciativa de política incorporada
Pode aplicar uma definição de política ou iniciativa no portal do Azure com os seguintes passos:
- Navegue para o serviço de Azure Policy no portal do Azure denominado Política.
- No painel esquerdo da página Azure Policy, selecione Definições.
- Em Categorias, selecione
Kubernetes
. - Escolha a definição de política ou iniciativa que pretende aplicar. Para este exemplo, selecione as normas de linha de base de segurança do pod de cluster do Kubernetes para a iniciativa cargas de trabalho baseadas em Linux .
- Selecione Atribuir.
- Defina o Âmbito para o grupo de recursos do cluster do AKS com o suplemento Azure Policy ativado.
- Selecione a página Parâmetros e atualize o Efeito de
audit
paradeny
para bloquear novas implementações que violem a iniciativa de linha de base. Também pode adicionar espaços de nomes adicionais para excluir da avaliação. Neste exemplo, mantenha os valores predefinidos. - Selecione Rever + criar>Criar para submeter a atribuição de política.
Criar e atribuir uma definição de política personalizada
As políticas personalizadas permitem-lhe definir regras para utilizar o Azure. Por exemplo, pode impor os seguintes tipos de regras:
- Práticas de segurança
- Gestão de custos
- Regras específicas da organização (como nomenclatura ou localizações)
Antes de criar uma política personalizada, verifique a lista de padrões e exemplos comuns para ver se o seu caso já está abrangido.
As definições de política personalizadas são escritas em JSON. Para saber mais sobre como criar uma política personalizada, veja Azure Policy estrutura de definições e Criar uma definição de política personalizada.
Nota
Azure Policy agora utiliza uma nova propriedade conhecida como templateInfo que lhe permite definir o tipo de origem para o modelo de restrição. Quando define templateInfo nas definições de política, não tem de definir propriedades constraintTemplate ou constraint . Ainda precisa de definir apiGroups e tipos. Para obter mais informações, veja Understanding Azure Policy effects (Compreender os efeitos Azure Policy).
Depois de criar a definição de política personalizada, veja Atribuir uma definição de política para obter instruções passo a passo sobre a atribuição da política ao cluster do Kubernetes.
Validar a execução de uma Azure Policy
Confirme que as atribuições de políticas são aplicadas ao cluster com o seguinte
kubectl get
comando.kubectl get constrainttemplates
Nota
As atribuições de políticas podem demorar até 20 minutos a sincronizar em cada cluster.
O resultado deve ser semelhante ao seguinte resultado de exemplo:
NAME AGE k8sazureallowedcapabilities 23m k8sazureallowedusersgroups 23m k8sazureblockhostnamespace 23m k8sazurecontainerallowedimages 23m k8sazurecontainerallowedports 23m k8sazurecontainerlimits 23m k8sazurecontainernoprivilege 23m k8sazurecontainernoprivilegeescalation 23m k8sazureenforceapparmor 23m k8sazurehostfilesystem 23m k8sazurehostnetworkingports 23m k8sazurereadonlyrootfilesystem 23m k8sazureserviceallowedports 23m
Validar a rejeição de um pod com privilégios
Primeiro, vamos testar o que acontece quando agenda um pod com o contexto de segurança do privileged: true
. Este contexto de segurança aumenta os privilégios do pod. A iniciativa não permite pods com privilégios, pelo que o pedido é negado, o que resulta na rejeição da implementação.
Crie um ficheiro com o nome
nginx-privileged.yaml
e cole o seguinte manifesto YAML.apiVersion: v1 kind: Pod metadata: name: nginx-privileged spec: containers: - name: nginx-privileged image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine securityContext: privileged: true
Crie o pod com o
kubectl apply
comando e especifique o nome do seu manifesto YAML.kubectl apply -f nginx-privileged.yaml
Conforme esperado, o pod não é agendado, conforme mostrado no seguinte exemplo de saída:
Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}
O pod não chega à fase de agendamento, pelo que não existem recursos para eliminar antes de avançar.
Testar a criação de um pod sem privilégios
No exemplo anterior, a imagem de contentor tentou utilizar automaticamente a raiz para vincular o NGINX à porta 80. A iniciativa de política nega este pedido, pelo que o pod não inicia. Agora, vamos tentar executar o mesmo pod NGINX sem acesso privilegiado.
Crie um ficheiro com o nome
nginx-unprivileged.yaml
e cole o seguinte manifesto YAML.apiVersion: v1 kind: Pod metadata: name: nginx-unprivileged spec: containers: - name: nginx-unprivileged image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
Crie o pod com o
kubectl apply
comando e especifique o nome do seu manifesto YAML.kubectl apply -f nginx-unprivileged.yaml
Verifique o estado do pod com o
kubectl get pods
comando .kubectl get pods
O resultado deve ser semelhante ao seguinte resultado de exemplo, que mostra que o pod foi agendado com êxito e tem o estado Em Execução:
NAME READY STATUS RESTARTS AGE nginx-unprivileged 1/1 Running 0 18s
Este exemplo mostra a iniciativa de linha de base que afeta apenas as implementações que violam as políticas na coleção. As implementações permitidas continuam a funcionar.
Elimine o pod sem privilégios do NGINX com o
kubectl delete
comando e especifique o nome do seu manifesto YAML.kubectl delete -f nginx-unprivileged.yaml
Desativar uma política ou iniciativa
Pode remover a iniciativa de linha de base no portal do Azure com os seguintes passos:
- Navegue para o painel Política no portal do Azure.
- Selecione Atribuições.
- Selecione o botão ... junto às normas de linha de base de segurança do pod do cluster do Kubernetes para a iniciativa de carga de trabalho baseada no Linux .
- Selecione Eliminar atribuição.
Passos seguintes
Para obter mais informações sobre como funciona Azure Policy, consulte os seguintes artigos:
Azure Kubernetes Service
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários