Compartilhar via

Proteja seu cluster usando as políticas de segurança de pods no Serviço de Kubernetes do Azure (AKS) (versão prévia)

  • Artigo

Importante

O recurso de política de segurança do pod foi preterido em 01º de agosto de 2023 e removido das versões 1.25 e superiores do AKS.

Recomendamos que você migre para o controlador de admissão de segurança do pod ou política do Azure para permanecer no Suporte do Azure. A Admissão de Segurança do Pod é uma solução de política interna para implementações de cluster único. Se você estiver procurando uma política de nível empresarial, o Azure Policy será uma opção melhor.

Antes de começar

  • Este artigo pressupõe que você tenha um cluster do AKS. Se você precisar de um cluster AKS, crie um usando a CLI do Azure, Azure PowerShell ou portal do Azure.
  • Você precisará da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Execute az --version para encontrar a versão. Caso precise instalá-la ou atualizá-la, confira instalar a CLI do Azure.

Instale a extensão aks-preview da CLI do Azure

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

  1. Instale a extensão aks-preview usando o comando az extension add.

    az extension add --name aks-preview

  2. Atualize para a última versão da extensão usando o comando az extension update.

    az extension update --name aks-preview

Registrar o sinalizador de recurso PodSecurityPolicyPreview

  1. Registre o sinalizador de recurso PodSecurityPolicyPreview usando o comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

    Demora alguns minutos para o status exibir Registrado.

  2. Verifique o status do registro usando o comando az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

  3. Quando o status reflete Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Visão geral de políticas de segurança de pods

Os clusters do Kubernetes usam controladores de admissão para interceptar solicitações ao servidor de API quando um recurso for criado. O controlador de admissão pode validar a solicitação de recurso em relação a um conjunto de regras ou modificar o recurso para alterar os parâmetros de implantação.

PodSecurityPolicy é um controlador de admissão que valida uma especificação de pod que atende aos seus requisitos definidos. Esses requisitos podem limitar o uso de contêineres com privilégios, o acesso a determinados tipos de armazenamento ou o usuário ou grupo no qual o contêiner pode ser executado. Quando você tenta implantar um recurso em que as especificações de pod não atendem aos requisitos descritos na política de segurança de pods, a solicitação é negada. Essa capacidade de controlar quais pods podem ser agendados no cluster do AKS impede algumas vulnerabilidades de segurança ou possíveis elevações de privilégios.

Quando você habilita a política de segurança de pods em um cluster do AKS, algumas políticas padrão são aplicadas. Essas políticas fornecem uma experiência pronta para uso para definir quais pods podem ser agendados. No entanto, você pode ter problemas ao implantar os pods até definir suas próprias políticas. A abordagem recomendada é:

  1. Criar um cluster do AKS.
  2. Defina suas próprias políticas de segurança de pods.
  3. Habilitar o recurso da política de segurança de pods.

Alterações de comportamento entre a política de segurança de pods e o Azure Policy

Cenário Política de segurança de pods Azure Policy
Instalação Habilitar o recurso de política de segurança de pods Habilitar o complemento do Azure Policy
Implantar políticas Implantar recurso de política de segurança de pods Atribua políticas do Azure à assinatura ou ao escopo do grupo de recursos. O complemento do Azure Policy é necessário para aplicativos de recurso de Kubernetes.
Políticas padrão Quando a política de segurança de pods é habilitada no AKS, as políticas padrão Com privilégios e Irrestrito são aplicadas. Nenhuma política padrão é aplicada habilitando o complemento do Azure Policy. Você deve habilitar explicitamente as políticas no Azure Policy.
Quem pode criar e atribuir políticas O administrador de cluster cria um recurso de política de segurança de pods Os usuários devem ter uma função mínima de permissões de 'proprietário' ou 'Colaborador de política de recurso' no grupo de recursos de cluster do AKS. -Por meio da API, os usuários podem atribuir políticas no escopo do recurso de cluster do AKS. O usuário deve ter o mínimo de permissões de 'proprietário' ou 'Colaborador de política de recurso' no recurso de cluster do AKS. -No portal do Azure, as políticas podem ser atribuídas no nível grupo de gerenciamento/assinatura/grupo de recursos.
Políticas de autorização Usuários e contas de serviço exigem permissões explícitas para usar políticas de segurança de pods. Nenhuma atribuição adicional é necessária para autorizar políticas. Depois que as políticas são atribuídas no Azure, todos os usuários do cluster podem usar essas políticas.
Aplicabilidade de política O usuário administrador ignora a imposição de políticas de segurança de pods. Todos os usuários (administradores e não administradores) veem as mesmas políticas. Não há uso de maiúsculas/minúsculas especiais com base nos usuários. O aplicativo de política pode ser excluído no nível de namespace.
Escopo da política As políticas de segurança do pods não têm namespace Os modelos de restrição usados pelo Azure Policy não estão com namespace.
Ação de negação/auditoria/mutação As políticas de segurança de pods dão suporte apenas a ações de negação. A mutação pode ser feita com valores padrão em solicitações de criação. A validação pode ser feita durante solicitações de atualização. O Azure Policy dá suporte às ações de auditoria e negação. Ainda não há suporte para mutação.
Conformidade da política de segurança de pods Não há visibilidade da conformidade dos pods que existiam antes de habilitar a política de segurança de pods. Os pods sem conformidade criados após a habilitação das políticas de segurança de pods são negados. Os pods sem conformidade que existiam antes de se aplicar as políticas do Azure apareciam em violações de política. Os pods sem conformidade criados após a habilitação das políticas do Azure serão negados se as políticas forem definidas com um efeito de negação.
Como exibir políticas no cluster kubectl get psp kubectl get constrainttemplate - Todas as políticas são retornadas.
Política de segurança de pods padrão - Com privilégios Um recurso de política de segurança de pods com privilégios é criado por padrão ao habilitar o recurso. O modo com privilégio não sugere nenhuma restrição, como resultado, é equivalente a não ter nenhuma atribuição do Azure Policy.
Política de segurança de pods padrão - Linha de base/padrão O usuário instala um recurso de linha de base de política de segurança de pods. O Azure Policy fornece uma iniciativa de linha de base interna que é mapeada para a política de segurança de pods de linha de base.
Política de segurança de pods padrão - Restrito O usuário instala um recurso restrito de política de segurança de pods. O Azure Policy fornece uma iniciativa restrita interna que é mapeada para a política de segurança de pods restrita.

Habilitar política de segurança de pods em um cluster do AKS

Observação

Em situações reais, não habilite a política de segurança de pods até definir suas próprias políticas personalizadas. Neste artigo, habilitamos a política de segurança de pods como a primeira etapa para ver como as políticas padrão limitam as implantações de pods.

  • Habilite a política de segurança de pods usando o comando az aks update.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-security-policy

Políticas do AKS padrão

Quando você habilita a política de segurança de pods, o AKS cria uma política padrão chamada privileged. Não edite ou remova a política padrão. Em vez disso, crie suas próprias políticas que definam as configurações que você deseja controlar. Primeiro, vamos examinar o que essas políticas padrão são e como elas afetam as implantações de pods.

  1. Exiba as políticas disponíveis usando o comando kubectl get psp.

    kubectl get psp

    Sua saída será parecida com o seguinte exemplo de saída:

    NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

    A política de segurança de pods privileged é aplicada a qualquer usuário autenticado no cluster do AKS. Essa atribuição é controlada por ClusterRoles e ClusterRoleBindings.

  2. Pesquise a associação default:privileged: no namespace kube-system usando o comando kubectl get rolebindings.

    kubectl get rolebindings default:privileged -n kube-system -o yaml

    A saída do exemplo condensado a seguir mostra que o psp:privileged ClusterRole está atribuído a qualquer usuário system:authenticated. Essa capacidade fornece um nível básico de privilégio sem que suas próprias políticas sejam definidas.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  [...]
  name: default:privileged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

É importante entender como essas políticas padrão interagem com as solicitações do usuário para agendar pods antes de começar a criar suas próprias políticas de segurança de pods. Nas próximas seções, agendamos alguns pods para ver as políticas padrão em ação.

Criar um usuário de teste em um cluster do AKS

Quando você usa o comando az aks get-credentials, as credenciais de administrador do cluster do AKS são adicionadas à sua configuração kubectl por padrão. O usuário administrador ignora a imposição de políticas de segurança de pods. Se você usar a integração do Microsoft Entra para seus clusters do AKS, poderá entrar com as credenciais de um usuário não administrador para ver a imposição de políticas em ação.

  1. Crie um namespace de exemplo chamado psp-aks para recursos de teste usando o comando kubectl create namespace.

    kubectl create namespace psp-aks

  2. Crie uma conta de serviço chamada nonadmin-user usando o comando kubectl create serviceaccount.

    kubectl create serviceaccount --namespace psp-aks nonadmin-user

  3. Crie um RoleBinding para o usuário não administrador executar ações básicas no namespace usando o comando kubectl create rolebinding.

    kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user

Criar comandos de alias para administrador e usuário não administrador

Ao usar kubectl, você pode destacar as diferenças entre o usuário administrador regular e o usuário não administrador criando dois aliases de linha de comando:

  1. O alias kubectl-admin é para o usuário administrador regular, que tem como escopo o namespace psp-aks.
  2. O alias kubectl-nonadminuser é para o nonadmin-user criado na etapa anterior, que tem como escopo o namespace psp-aks.

  • Crie os dois aliases usando os seguintes comandos.

    alias kubectl-admin='kubectl --namespace psp-aks'
alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'

Testar a criação de um pod com privilégio

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 política de segurança do AKS de privilégio padrão deve negar essa solicitação.

  1. Crie um arquivo chamado nginx-privileged.yaml e cole o conteúdo do seguinte manifesto YAML.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        privileged: true

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

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    A saída de exemplo a seguir mostra que o pod não pôde ser agendado:

    Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []

    Como o pod não atinge o estágio de agendamento, não há recursos para excluir antes de prosseguir.

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

No exemplo anterior, a especificação de pod solicitou elevação com privilégios. Essa solicitação é negada pela política de segurança de pods de privilégio padrão, portanto, o pod não será agendado. Vamos tentar executar o mesmo pod NGINX sem a solicitação de elevação de privilégio.

  1. Crie um arquivo chamado nginx-unprivileged.yaml e cole o conteúdo do seguinte manifesto YAML.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine

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

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    A saída de exemplo a seguir mostra que o pod não pôde ser agendado:

    Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []

    Como o pod não atinge o estágio de agendamento, não há recursos para excluir antes de prosseguir.

Testar a criação de um pod com um contexto de usuário específico

No exemplo anterior, a imagem de contêiner tentou usar root automaticamente para vincular o NGINX à porta 80. Essa solicitação foi negada pela política de segurança de pods de privilégio padrão, portanto, o pod não será iniciado. Vamos tentar executar o mesmo pod NGINX com um contexto de usuário específico, como runAsUser: 2000.

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

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        runAsUser: 2000

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

    kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

    A saída de exemplo a seguir mostra que o pod não pôde ser agendado:

    Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []

    Como o pod não atinge o estágio de agendamento, não há recursos para excluir antes de prosseguir.

Criar uma política de segurança de pods personalizada

Agora que você viu o comportamento das políticas de segurança de pods padrão, vamos fornecer uma maneira para o nonadmin-user agendar pods com êxito.

Vamos criar uma política para rejeitar os pods que solicitam acesso privilegiado. Outras opções, como runAsUser ou volumes permitidos, não são explicitamente restritas. Esse tipo de política nega uma solicitação de acesso privilegiado, mas permite que o cluster execute os pods solicitados.

  1. Crie um arquivo chamado psp-deny-privileged.yaml e cole no manifesto YAML a seguir.

    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-deny-privileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
 - '*'

  2. Crie a política usando o comando kubectl apply e especifique o nome do seu manifesto YAML.

    kubectl apply -f psp-deny-privileged.yaml

  3. Exiba as políticas disponíveis usando o comando kubectl get psp.

    kubectl get psp

    No exemplo de saída a seguir, compare a política psp-deny-privileged com a política padrão de privilégio imposta nos exemplos anteriores para criar um pod. Somente o uso de escalonamento de PRIV é negado pela sua política. Não há restrições no usuário ou grupo para a política psp-deny-privileged.

    NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *

Permitir que a conta de usuário use a política de segurança de pods personalizada

Na etapa anterior, você criou uma política de segurança de pods para rejeitar pods que solicitam acesso privilegiado. Para permitir que a política seja usada, você cria um Role ou um ClusterRole. Em seguida, você associa uma dessas funções usando um RoleBinding ou ClusterRoleBinding. Para este exemplo, criaremos um ClusterRole que permite que você use a política psp-deny-privileged criada na etapa anterior.

  1. Crie um arquivo chamado psp-deny-privileged-clusterrole.yaml e cole no manifesto YAML a seguir.

    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
  - extensions
   resources:
  - podsecuritypolicies
   resourceNames:
  - psp-deny-privileged
   verbs:
  - use

  2. Crie o ClusterRole usando o comando kubectl apply e especifique o nome do seu manifesto YAML.

    kubectl apply -f psp-deny-privileged-clusterrole.yaml

  3. Crie um arquivo chamado psp-deny-privileged-clusterrolebinding.yaml e cole no manifesto YAML a seguir.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp-deny-privileged-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-deny-privileged-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

  4. Crie o ClusterRoleBinding usando o comando kubectl apply e especifique o nome do seu manifesto YAML.

    kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml

Observação

Na primeira etapa deste artigo, o recurso de política de segurança de pods foi habilitado no cluster do AKS. A prática recomendada era habilitar apenas o recurso de política de segurança de pods depois de definir suas próprias políticas. Este é o estágio em que você habilitaria o recurso de política de segurança de pods. Uma ou mais políticas personalizadas foram definidas, e as contas de usuário foram associadas a essas políticas. Agora você pode habilitar com segurança o recurso da política de segurança de pods e minimizar os problemas causados pelas políticas padrão.

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

Com a política de segurança de pods personalizada aplicada e uma associação para a conta de usuário usar a política, vamos tentar criar um pod sem privilégios novamente.

Este exemplo mostra como você pode criar políticas de segurança de pods personalizadas para definir o acesso ao cluster AKS para usuários ou grupos diferentes. As políticas de AKS padrão fornecem controles rígidos sobre quais pods podem ser executados, portanto, crie suas próprias políticas personalizadas para, então, definir corretamente as restrições necessárias.

  1. Use o manifesto nginx-privileged.yaml para criar o pod usando o comando kubectl apply.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

  2. Verifique o status de pod usando o comando kubectl get pods.

    kubectl-nonadminuser get pods

    A saída de exemplo a seguir mostra que o pod foi agendado com sucesso e está em Execução:

    NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s

  3. Exclua o pod sem privilégios NGINX usando o comando kubectl delete e especifique o nome do seu manifesto YAML.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Limpar os recursos

  1. Desabilite a política de segurança de pods usando o comando az aks update.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-pod-security-policy

  2. Exclua o ClusterRole e ClusterRoleBinding usando o comando kubectl delete.

    kubectl delete -f psp-deny-privileged-clusterrole.yaml

  3. Exclua o ClusterRoleBinding usando o comando kubectl delete.

    kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml

  4. Exclua a política de segurança usando o comando kubectl delete e especifique o nome do seu manifesto YAML.

    kubectl delete -f psp-deny-privileged.yaml

  5. Exclua o namespace psp-aks usando o comando kubectl delete.

    kubectl delete namespace psp-aks

Próximas etapas

Este artigo mostrou como criar uma política de segurança de pods para evitar o uso de acesso privilegiado. As políticas podem impor muitos recursos, como o tipo de volume ou o usuário RunAs. Para obter mais informações sobre as opções disponíveis, consulte os documentos de referência de política de segurança de pods do Kubernetes.

Para mais informações sobre a limitação do tráfego de rede de pods, consulte Proteger o tráfego entre os pods usando as políticas de rede no AKS.