Proteger os clusters do Azure Kubernetes Service (AKS) com Azure Policy

  • Artigo

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

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:

  1. Navegue para o serviço de Azure Policy no portal do Azure denominado Política.
  2. No painel esquerdo da página Azure Policy, selecione Definições.
  3. Em Categorias, selecione Kubernetes.
  4. 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 .
  5. Selecione Atribuir.
  6. Defina o Âmbito para o grupo de recursos do cluster do AKS com o suplemento Azure Policy ativado.
  7. Selecione a página Parâmetros e atualize o Efeito de audit para deny 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.
  8. 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.

  1. 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

  2. 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.

  1. 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

  2. Crie o pod com o kubectl apply comando e especifique o nome do seu manifesto YAML.

    kubectl apply -f nginx-unprivileged.yaml

  3. 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.

  4. 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:

  1. Navegue para o painel Política no portal do Azure.
  2. Selecione Atribuições.
  3. 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 .
  4. Selecione Eliminar atribuição.

Passos seguintes

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