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

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

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

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

• 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
   

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.