Partilhar via

Proteger o seu cluster através de políticas de segurança de pod no Azure Kubernetes Service (pré-visualização)

  • Artigo

Importante

O recurso de política de segurança do pod foi preterido em 1º 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 para a política do Azure para permanecer no suporte do Azure. O Pod Security Admission é uma solução de política integrada para implementações de cluster único. Se você estiver procurando por uma política de nível empresarial, a política do Azure é uma escolha melhor.

Antes de começar

  • Este artigo pressupõe que você tenha um cluster AKS existente. Se você precisar de um cluster AKS, crie um usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
  • Você precisa da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Executar az --version para localizar a versão. Se você precisar instalar ou atualizar, consulte instalar a CLI do Azure.

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

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

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

    az extension add --name aks-preview

  2. Atualize para a versão mais recente da extensão usando o az extension update comando.

    az extension update --name aks-preview

Registrar o sinalizador de PodSecurityPolicyPreview recurso

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

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

    Leva alguns minutos para que o status mostre Registrado.

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

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

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

    az provider register --namespace Microsoft.ContainerService

Visão geral das políticas de segurança do pod

Os clusters Kubernetes usam controladores de admissão para intercetar solicitações para o servidor de API quando um recurso será criado. O controlador de admissão pode então validar a solicitação de recurso em relação a um conjunto de regras ou mutar 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 privilegiados, o acesso a certos tipos de armazenamento ou o usuário ou grupo como o contêiner pode ser executado. Quando você tenta implantar um recurso em que as especificações do pod não atendem aos requisitos descritos na política de segurança do pod, a solicitação é negada. Essa capacidade de controlar quais pods podem ser agendados no cluster AKS evita algumas possíveis vulnerabilidades de segurança ou escalonamentos de privilégios.

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

  1. Crie um cluster AKS.
  2. Defina suas próprias políticas de segurança do pod.
  3. Habilite o recurso de política de segurança do pod.

Alterações de comportamento entre a política de segurança do pod e a Política do Azure

Cenário Política de segurança do pod Azure Policy
Instalação Ativar o recurso de política de segurança do pod Habilitar o Complemento de Política do Azure
Implantar políticas Implantar recurso de política de segurança do pod Atribua políticas do Azure ao escopo da assinatura ou do grupo de recursos. O Complemento de Política do Azure é necessário para aplicativos de recursos do Kubernetes.
Políticas padrão Quando a política de segurança do pod está habilitada no AKS, as políticas padrão Privilegiado e Irrestrito são aplicadas. Nenhuma política padrão é aplicada habilitando o Complemento de Política do Azure. Você deve habilitar explicitamente as políticas na Política do Azure.
Quem pode criar e atribuir políticas O administrador de cluster cria um recurso de política de segurança de pod Os usuários devem ter uma função mínima de permissões de 'proprietário' ou 'Colaborador de Política de Recursos' no grupo de recursos do cluster AKS. - Através da API, os usuários podem atribuir políticas no escopo de recursos do cluster AKS. O usuário deve ter um mínimo de permissões de 'proprietário' ou 'Colaborador de Política de Recursos' no recurso de cluster AKS. - No portal do Azure, as políticas podem ser atribuídas no nível do 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 pod. 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 das políticas O usuário administrador ignora a aplicação de políticas de segurança do pod. Todos os usuários (admin ou non-admin) veem as mesmas políticas. Não há invólucro especial com base nos usuários. O aplicativo de política pode ser excluído no nível do namespace.
Âmbito da política As políticas de segurança do pod não são namespaced Os modelos de restrição usados pela Política do Azure não são namespaceados.
Ação de negação/auditoria/mutação As políticas de segurança do Pod suportam apenas 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 as solicitações de atualização. A Política do Azure dá suporte a ambas as ações de auditoria e negação. A mutação ainda não é suportada.
Conformidade com a política de segurança do Pod Não há visibilidade sobre a conformidade dos pods que existiam antes de ativar a política de segurança do pod. Os pods não compatíveis criados após a ativação das políticas de segurança do pod são negados. Os pods não compatíveis que existiam antes da aplicação das políticas do Azure apareceriam em violações de política. Os pods não compatíveis 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 apólices são devolvidas.
Padrão de política de segurança do pod - Privilegiado Um recurso de política de segurança de pod privilegiado é criado por padrão ao ativar o recurso. O modo privilegiado não implica nenhuma restrição, como resultado, é equivalente a não ter nenhuma atribuição de Política do Azure.
Padrão da política de segurança do pod - Linha de base/padrão O usuário instala um recurso de linha de base da política de segurança do pod. A Política do Azure fornece uma iniciativa de linha de base interna que mapeia para a política de segurança do pod de linha de base.
Padrão de política de segurança do pod - Restrito O usuário instala um recurso restrito de política de segurança do pod. A Política do Azure fornece uma iniciativa restrita interna que mapeia para a política de segurança de pod restrito.

Ativar a política de segurança do pod em um cluster AKS

Nota

Para uso no mundo real, não habilite a política de segurança do pod até definir suas próprias políticas personalizadas. Neste artigo, habilitamos a política de segurança do pod como a primeira etapa para ver como as políticas padrão limitam as implantações do pod.

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

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

Políticas AKS padrão

Quando você ativa a política de segurança do pod, o AKS cria uma política padrão chamada privileged. Não edite nem remova a política padrão. Em vez disso, crie suas próprias políticas que definem as configurações que você deseja controlar. Vamos primeiro ver quais são essas políticas padrão, como elas afetam as implantações de pod.

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

    kubectl get psp

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

    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 pod privilegiado é aplicada a qualquer usuário autenticado no cluster AKS. Esta atribuição é controlada por ClusterRoles e ClusterRoleBindings.

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

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

    A saída de exemplo condensada a seguir mostra que o psp:privileged ClusterRole é 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 pod. 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 AKS

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

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

    kubectl create namespace psp-aks

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

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

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

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

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

Ao usar kubectlo , 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 privilegiado

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

  1. Crie um arquivo nomeado 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 kubectl apply comando e especifique o nome do seu manifesto YAML.

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    O exemplo de saída a seguir mostra que o pod não pô não pô 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 seguir em frente.

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

No exemplo anterior, a especificação do pod solicitava escalonamento privilegiado. Essa solicitação é negada pela política de segurança do pod de privilégio padrão, portanto, o pod não pode ser agendado. Vamos tentar executar o mesmo pod NGINX sem a solicitação de escalonamento de privilégios.

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

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    O exemplo de saída a seguir mostra que o pod não pô não pô 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 seguir em frente.

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

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

  1. Crie um arquivo nomeado nginx-unprivileged-nonroot.yaml e cole no seguinte manifesto YAML.

    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 kubectl apply comando e especifique o nome do seu manifesto YAML.

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

    O exemplo de saída a seguir mostra que o pod não pô não pô 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 seguir em frente.

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

Agora que você já viu o comportamento das políticas de segurança de pod padrão, vamos fornecer uma maneira para o usuário não-administrador agendar pods com êxito.

Criaremos uma política para rejeitar 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 nomeado psp-deny-privileged.yaml e cole no seguinte manifesto YAML.

    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 kubectl apply comando e especifique o nome do seu manifesto YAML.

    kubectl apply -f psp-deny-privileged.yaml

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

    kubectl get psp

    Na saída do exemplo a seguir, compare a política psp-deny-privileged com a política de privilégio padrão que foi imposta nos exemplos anteriores para criar um pod. Apenas o uso do escalonamento PRIV é negado pela sua política. Não há restrições sobre o 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 pod personalizada

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

  1. Crie um arquivo nomeado psp-deny-privileged-clusterrole.yaml e cole no seguinte manifesto YAML.

    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 kubectl apply comando e especifique o nome do seu manifesto YAML.

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

  3. Crie um arquivo nomeado psp-deny-privileged-clusterrolebinding.yaml e cole no seguinte manifesto YAML.

    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 kubectl apply comando e especifique o nome do seu manifesto YAML.

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

Nota

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

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

Com sua política de segurança de pod 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 pod personalizadas para definir o acesso ao cluster AKS para diferentes usuários ou grupos. As políticas AKS padrão fornecem controles rígidos sobre quais pods podem ser executados, portanto, crie suas próprias políticas personalizadas para definir corretamente as restrições necessárias.

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

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

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

    kubectl-nonadminuser get pods

    O exemplo de saída a seguir mostra que o pod foi agendado com êxito 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 kubectl delete comando e especifique o nome do seu manifesto YAML.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Clean up resources (Limpar recursos)

  1. Desative a política de segurança do pod usando o az aks update comando.

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

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

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

  3. Exclua o ClusterRoleBinding usando o kubectl delete comando.

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

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

    kubectl delete -f psp-deny-privileged.yaml

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

    kubectl delete namespace psp-aks

Próximos passos

Este artigo mostrou como criar uma política de segurança de pod para impedir 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 da política de segurança do pod do Kubernetes.

Para obter mais informações sobre como limitar o tráfego de rede do pod, consulte Proteger o tráfego entre pods usando políticas de rede no AKS.