Proteja seus clusters do Serviço de Kubernetes do Azure (AKS) com o Azure Policy

Artigo
08/02/2024

Você pode aplicar e impor políticas de segurança integradas em seus clusters do Serviço de Kubernetes do Azure (AKS) usando o Azure Policy. O Azure Policy ajuda a impor os padrões organizacionais e a avaliar a conformidade em escala. Após você instalar o complemento Azure Policy 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 policysets) ao seu cluster. Consulte as definições internas da Política do Azure para AKS para obter uma lista completa de definições de políticas e iniciativas 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 do AKS. Se você precisar de um cluster do AKS, poderá criá-lo usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
Você precisa ter o complemento Azure Policy para AKS instalado em seu cluster AKS.

Atribuir uma definição de política incorporada

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

Navegue até o serviço de Azure Policy no portal do Azure chamado Política.
No painel esquerdo da página do Azure Policy, selecione Definições.
Em Categorias, selecione Kubernetes.
Escolha a definição de política ou a iniciativa que você deseja aplicar. Para este exemplo, selecione a iniciativa Padrões de linha de base de segurança do pod do cluster do Kubernetes para cargas de trabalho baseadas em Linux.
Selecione Atribuir.
Defina o Escopo para o grupo de recursos do cluster do AKS com o complemento Azure Policy habilitado.
Selecione a página Parâmetros e atualize o Efeito de audit para deny para bloquear novas implantações violando a iniciativa de linha de base. Você também pode adicionar namespaces extras para excluir da avaliação. Para este exemplo, mantenha os valores padrão.
Selecione Examinar + criar>Criar para enviar 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
Gerenciamento de custo
Regras específicas da organização (como nomeação 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 programadas em JSON. Para saber mais sobre como criar uma política personalizada, confira Estrutura de definição do Azure Policy e Criar uma definição de política personalizada.

Observação

O Azure Policy agora utiliza uma nova propriedade conhecida como templateInfo que permite que você defina o tipo de fonte para o modelo de restrição. Quando você define templateInfo em definições de política, você não precisa definir constraintTemplate ou propriedades de restrição. Você ainda precisa definir apiGroups e tipos. Para obter mais informações, confira Noções básicas dos efeitos do Azure Policy.

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

Validar se uma Azure Policy está em execução

Confirme se as atribuições de política foram aplicadas ao seu cluster usando o seguinte comando kubectl get.

kubectl get constrainttemplates

Observação

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 do 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

Primeiro, vamos testar o que acontece quando você agenda um pod com o contexto de segurança de privileged: true. Esse contexto de segurança aumenta os privilégios do pod. A iniciativa não permite pods privilegiados, portanto a solicitação é negada, o que resulta na rejeição da implantação.

Crie um arquivo chamado nginx-privileged.yaml e cole no manifesto YAML a seguir.

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 comando kubectl apply 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 do 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 chega ao estágio de programação, portanto, não há recursos para excluir antes de você prosseguir.

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

No exemplo anterior, a imagem do contêiner tentou usar root automaticamente para vincular o NGINX à porta 80. A iniciativa de política nega essa solicitação, portanto, o pod não consegue iniciar. Agora, vamos tentar executar o mesmo pod NGINX sem acesso privilegiado.

Crie um arquivo chamado nginx-unprivileged.yaml e cole no manifesto YAML a seguir.

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 comando kubectl apply e especifique o nome do seu manifesto YAML.
```
kubectl apply -f nginx-unprivileged.yaml
```
Verifique o status de pod usando o comando kubectl get pods.
```
kubectl get pods
```
Sua saída deve ser semelhante à saída do exemplo a seguir, que mostra que o pod foi agendado com sucesso e tem um status de Será executado:
```
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 da coleção. As implantações permitidas continuam a funcionar.
Exclua o pod sem privilégios NGINX usando o comando kubectl delete e especifique o nome do seu manifesto YAML.
```
kubectl delete -f nginx-unprivileged.yaml
```

Desabilitar uma política ou iniciativa

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

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

Próximas etapas

Para obter mais informações sobre como o Azure Policy funciona, consulte os artigos a seguir:

Partilhar via