Proteja seus clusters do Serviço Kubernetes do Azure (AKS) com a Política do Azure

Artigo
11/22/2024

Você pode aplicar e impor políticas de segurança internas em seus clusters do Serviço Kubernetes do Azure (AKS) usando a Política do Azure. A Política do Azure ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Depois de instalar o complemento de Política do Azure para AKS, você pode aplicar definições de política individuais ou grupos de definições de política chamadas iniciativas (às vezes chamadas de conjuntos de políticas) ao seu cluster. Consulte Definições internas da Política do Azure para AKS para obter uma lista completa das definições de política e iniciativa do AKS.

Este artigo mostra como aplicar definições de política ao cluster e verificar se essas atribuições estão sendo impostas.

Pré-requisitos

Este artigo pressupõe que você tenha um cluster AKS existente. Se precisar de um cluster AKS, você pode criar um usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
Você precisa do complemento de Política do Azure para AKS instalado em seu cluster AKS.

Atribuir uma definição ou iniciativa de política interna

Você pode aplicar uma definição de política ou iniciativa no portal do Azure usando as seguintes etapas:

Navegue até o serviço de Política do Azure no portal do Azure chamado Política.
No painel esquerdo da página Política do Azure, selecione Definições.
Em Categorias, selecione Kubernetes.
Escolha a definição de política ou a iniciativa a que pretende candidatar-se. Para este exemplo, selecione a iniciativa Kubernetes cluster pod security baseline standards for Linux-based workloads .
Selecione Atribuir.
Defina o Escopo para o grupo de recursos do cluster AKS com o complemento Azure Policy habilitado.
Selecione a página Parâmetros e atualize o Efeito de para deny para bloquear novas implantações que violem a iniciativa de linha de audit base. Você também pode adicionar namespaces extras para excluir da avaliação. Para este exemplo, mantenha os valores padrão.
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 definir regras para usar o Azure. Por exemplo, você 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á coberto.

As definições de política personalizadas são escritas em JSON. Para saber mais sobre como criar uma política personalizada, consulte Estrutura de definição de política do Azure e Criar uma definição de política personalizada.

Nota

O Azure Policy agora utiliza uma nova propriedade conhecida como templateInfo , que permite definir o tipo de origem para o modelo de restrição. Ao definir templateInfo em definições de política, não é necessário definir constraintTemplate ou propriedades de restrição . Você ainda precisa definir apiGroups e tipos. Para obter mais informações sobre isso, consulte Noções básicas sobre os efeitos da Política do Azure.

Depois de criar sua definição de política personalizada, consulte Atribuir uma definição de política para obter um passo a passo sobre como atribuir a política ao cluster do Kubernetes.

Validar se uma Política do Azure está em execução

Confirme se as atribuições de política são aplicadas ao cluster usando o comando a seguir kubectl get .

kubectl get constrainttemplates

Nota

As atribuições de política podem levar até 20 minutos para serem sincronizadas em cada cluster.

Sua saída deve ser semelhante à saída de exemplo a seguir:

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 privilegiado

Vamos primeiro testar o que acontece quando você agenda um pod com o contexto de segurança do privileged: true. Esse contexto de segurança aumenta os privilégios do pod. A iniciativa desautoriza pods privilegiados, por isso o pedido é negado, o que resulta na rejeição da implantação.

Crie um arquivo nomeado nginx-privileged.yaml e cole no 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 usando o kubectl apply comando e especifique o nome do seu manifesto YAML.

kubectl apply -f nginx-privileged.yaml

Como esperado, o pod não consegue ser agendado, conforme mostrado na saída de exemplo a seguir:

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 atinge o estágio de agendamento, portanto, não há recursos para excluir antes de seguir em frente.

Testar a criação de um pod sem privilégios

No exemplo anterior, a imagem do contêiner tentou usar automaticamente o root para vincular o NGINX à porta 80. A iniciativa política nega este pedido, pelo que o pod não arranca. Agora, vamos tentar executar esse mesmo pod NGINX sem acesso privilegiado.

Crie um arquivo nomeado nginx-unprivileged.yaml e cole no 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 usando o kubectl apply comando e especifique o nome do seu manifesto YAML.
```
kubectl apply -f nginx-unprivileged.yaml
```
Verifique o status do pod usando o kubectl get pods comando.
```
kubectl get pods
```
Sua saída deve ser semelhante à saída de exemplo a seguir, que mostra que o pod foi agendado com êxito e tem um status de 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 implantações que violam as políticas na coleção. As implantações permitidas continuam funcionando.
Exclua o pod sem privilégios NGINX usando o kubectl delete comando e especifique o nome do seu manifesto YAML.
```
kubectl delete -f nginx-unprivileged.yaml
```

Desativar uma política ou iniciativa

Você pode remover a iniciativa de linha de base no portal do Azure usando as seguintes etapas:

Navegue até o painel Política no portal do Azure.
Selecione Tarefas.
Selecione o botão ... ao lado dos padrões de linha de base de segurança do pod de cluster do Kubernetes para a iniciativa de carga de trabalho baseada em Linux.
Selecione Excluir atribuição.

Próximos passos

Para obter mais informações sobre como funciona a Política do Azure, consulte os seguintes artigos:

Descrição geral do Azure Policy
Iniciativas e políticas do Azure Policy para AKS
Remova o complemento Azure Policy.

Partilhar via