Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo mostra como usar as Proteções de Implantação para impor práticas recomendadas em um cluster do AKS (Serviço de Kubernetes do Azure).
Visão geral
Observação
As Proteções de Implantação são ativadas por padrão no AKS Automatic.
Ao longo do ciclo de vida de desenvolvimento, é comum que bugs, problemas e outros problemas surjam se a implantação inicial dos recursos do Kubernetes incluir configurações incorretas. Para aliviar a carga do desenvolvimento do Kubernetes, o AKS (Serviço de Kubernetes do Azure) oferece proteções de implantação. As Proteções de Implantação impõem as melhores práticas do Kubernetes em seu cluster do AKS por meio dos controles do Azure Policy.
As Proteções de Implantação oferecem dois níveis de configuração:
-
Warn: exibe mensagens de aviso no terminal de código para alertar você sobre as configurações de cluster fora de conformidade, mas ainda permite que a solicitação seja concluída. -
Enforce: impõe configurações que estão em conformidade, negando e modificando as implantações se elas não seguem as melhores práticas.
Depois de configurar as Proteções de Implantação para 'Avisar' ou 'Impor', as Proteções de Implantação avaliam programaticamente seus recursos do Kubernetes no momento da criação ou da atualização para conformidade. As Proteções de Implantação também exibem informações de conformidade agregadas em suas cargas de trabalho no nível de cada recurso, por meio do painel de conformidade do Azure Policy no portal do Azure ou em sua CLI ou terminal. A execução de uma carga de trabalho não compatível indica que o cluster não está seguindo as práticas recomendadas e que as cargas de trabalho em seu cluster correm o risco de apresentar problemas causados pela configuração do cluster.
Pré-requisitos
Observação
Os administradores de cluster não precisam de permissões do Azure Policy para habilitar ou desabilitar as Proteções de Implantação. No entanto, é necessário ter o complemento do Azure Policy instalado.
- Você precisa habilitar o complemento do Azure Policy para o AKS. Para obter mais informações, confira Habilitar o Azure Policy no seu cluster do AKS. Isso inclui o registro do provedor de recursos
Microsoft.PolicyInsightsem sua assinatura.
Políticas de proteções de implantação
Quando você habilita as Salvaguardas de Implantação, a tabela a seguir lista as políticas que se tornam ativas e os recursos do Kubernetes que elas direcionam. Você pode exibir as Proteções de Implantação atualmente disponíveis no portal do Azure como uma definição do Azure Policy ou em definições internas do Azure Policy para o Serviço de Kubernetes do Azure. A intenção por trás dessa coleção é criar uma lista comum e genérica de melhores práticas aplicáveis à maioria dos usuários e casos de uso.
| Política de implantação de medidas de segurança | Resultado da mutação, se disponível |
|---|---|
| Não é possível editar nós individuais | N/D |
| As requisições de recursos de memória e CPU dos contêineres do cluster Kubernetes devem ser definidas. | Define solicitações de CPU e memória padrão e impõe mínimos. Para obter mais informações, consulte o modificador de solicitações de recurso. |
| É necessário ter regras antiafinidade ou topologySpreadConstraintsSet | Adiciona regras de antiafinidade de pod e restrições de espalhamento de topologia para melhorar a distribuição de workload. Para obter mais informações, consulte o modificador de antiafinidade e distribuição de topologia. |
| Nenhum rótulo específico do AKS | N/D |
| Os contêineres de cluster do Kubernetes devem usar somente as imagens permitidas | N/D |
| Taints do sistema de pool reservado | Remove o taint CriticalAddonsOnly de um pool de nós de usuário se ele não está definido. O AKS usa o taint CriticalAddonsOnly para manter os pods do cliente longe do pool do sistema. Essa configuração garante uma separação clara entre os componentes do AKS e os pods de cliente e impede a remoção de pods de clientes que não toleram o taint CriticalAddonsOnly. |
| Verificar se os contêineres de cluster têm investigações de preparação ou atividade configuradas | N/D |
| Os clusters do Kubernetes devem usar o StorageClass do driver da CSI (Interface de Armazenamento de Contêiner) | N/D |
| Os serviços de cluster do Kubernetes devem usar seletores exclusivos | N/D |
| As imagens de contêiner de cluster do Kubernetes não devem incluir a tag de imagem mais recente | N/D |
Se você quiser enviar uma ideia ou solicitação de Proteções de Implantação, abra um problema no repositório GitHub do AKS e adicione [Deployment Safeguards request] ao início do título.
Modificador de solicitações de recurso
Quando as Proteções de Implantação são definidas para o Enforce nível, o modificador de solicitações de recurso define automaticamente solicitações de CPU e memória e limites para contêineres que não os têm definidos ou têm valores abaixo dos limites mínimos.
Valores padrão
Quando nenhum recurso é especificado, o modificador define os seguintes valores padrão:
| Resource | Solicitação | Limit |
|---|---|---|
| CPU | 500 m | 500 m |
| Memória | 2048Mi (2Gi) | 2048Mi (2Gi) |
Fiscalização mínima
Quando os recursos são especificados, mas estão abaixo dos limites, o modificador impõe os seguintes valores mínimos:
| Resource | Valor mínimo |
|---|---|
| CPU | 100m |
| Memória | 100Mi |
Noções básicas sobre unidades de recursos
Unidades de CPU:
-
m= milicoros (1m= 1/1.000 de um core de CPU) -
1000m= 1 núcleo de CPU completo -
500m= 0,5 núcleos de CPU (meio núcleo) -
100m= 0,1 núcleos de CPU (10% de um núcleo)
Unidades de memória:
-
Mi= Mebibytes (binário: 1 Mi = 1.024 × 1.024 bytes) -
Gi= Gibibytes (binário: 1 Gi = 1.024 Mi) 2048Mi=2Gi-
100Mi≈ 105 MB
Regras de mutação da CPU
O modificador aplica a seguinte lógica para recursos de CPU:
| Scenario | Ação |
|---|---|
| A solicitação e o limite da CPU estão ausentes | Definir ambos como 500m (padrão) |
A solicitação de CPU existe, mas é menor que 100m |
Definir a solicitação como 100m (mínimo) |
O limite da CPU existe, mas é menor que 100m |
Definir limite como 100m (mínimo) |
| Somente a solicitação de CPU existe | Definir solicitação igual ao limite |
| Existe apenas o limite de CPU | Definir solicitação igual ao limite |
Regras de mutação de memória
O modificador aplica a seguinte lógica para recursos de memória:
| Scenario | Ação |
|---|---|
| A solicitação de memória e o limite estão ausentes | Definir ambos como 2048Mi (padrão) |
A solicitação de memória existe, mas é menor que 100Mi |
Definir a solicitação como 100Mi (mínimo) |
O limite de memória existe, mas é menor que 100Mi |
Definir limite como 100Mi (mínimo) |
| Somente a solicitação de memória existe | Deixar como está (sem limite incluído) |
| Existe apenas o limite de memória | Deixar como está (nenhuma solicitação adicionada) |
Correção da classe QoS (Qualidade de Serviço) do Kubernetes
Depois que as mutações de CPU e memória forem aplicadas, se o valor da solicitação exceder o limite para o mesmo tipo de recurso, o mutador limitará a solicitação para corresponder ao limite. Essa correção mantém configurações de classe QoS (Qualidade de Serviço) do Kubernetes válidas.
Casos que sofreram mutação
O modificador de solicitações de recurso aplica alterações nos seguintes cenários:
-
Recursos vazios: contêineres sem solicitações de CPU ou memória ou limites recebem valores padrão (
500mCPU,2048Mimemória). -
Abaixo dos limites mínimos: as solicitações de CPU ou os limites abaixo
100msão aumentados para100m. As solicitações de memória ou os limites abaixo100Misão aumentados para100Mi. - Cenários de QoS inválidos: quando as solicitações excedem os limites, as solicitações são reduzidas para corresponder aos limites.
- Especificações parciais de recursos: Contêineres com apenas requisições ou apenas limites (mas não ambos) têm mínimos impostos quando especificados.
- Vários contêineres: todos os contêineres em um pod são processados e modificados adequadamente.
- Namespaces habilitados: somente workloads em namespaces em que a proteção está habilitada são alteradas.
Casos que não são mutacionados
O modificador de solicitações de recurso não aplica alterações nos seguintes cenários:
- Namespaces excluídos: cargas de trabalho em namespaces em que a proteção é excluída permanecem inalteradas.
- Recursos já compatíveis: os contêineres que já têm solicitações e limites acima dos limites mínimos permanecem inalterados.
- Configurações de QoS válidas: quando as solicitações são menores ou iguais aos limites e ambos os valores estão acima dos mínimos, nenhuma alteração ocorre.
Alterador de propagação de antiafinidade e topologia
Quando as Proteções de Implantação são definidas no nível Enforce, o modificador de antiafinidade e propagação de topologia adiciona automaticamente regras de antiafinidade de pod e restrições de propagação de topologia para melhorar a distribuição de workload entre nós.
Quando o modificador é executado
O modificador é executado somente quando todas as seguintes condições são atendidas:
- As restrições de antiafinidade de pod e de dispersão de topologia ainda não estão configuradas na workload.
- O namespace não é excluído das Proteções de Implantação.
- As implantações de medidas de segurança estão no modo
Enforce. - A carga de trabalho não tem o
kubernetes.azure.com/managedby=aksrótulo.
O que o modificador adiciona
Identificação de etiquetas: o modificador identifica pods usando a seguinte prioridade de etiquetas:
-
apprótulo (primeira prioridade) -
app.kubernetes.io/namerótulo (segunda prioridade) - Cria um
default-antiaffinity-applabel=<workload-name>rótulo (fallback)
Antiafinidade de pod: adiciona uma regra preferencial de antiafinidade de pod com peso 100, que prefere agendar pods com rótulos correspondentes em nós diferentes. Usa a chave kubernetes.io/hostnamede topologia.
Restrições de propagação de topologia: adiciona uma restrição com as seguintes configurações:
| Configurações | Value |
|---|---|
| MaxSkew | 1 (permite uma diferença máxima de 1 pod por nó) |
| WhenUnsatisfiable | ScheduleAnyway (melhor esforço, não bloqueia o agendamento) |
| Chave de topologia | kubernetes.io/hostname |
Casos que sofreram mutação
O modificador de antiafinidade e propagação de topologia aplica alterações nos seguintes cenários:
-
Workloads com
apprótulo: usa o valor doapprótulo para seletores de antiafinidade e de distribuição de topologia. -
Workloads com
app.kubernetes.io/namelabel: quando não existe nenhum rótuloapp, esse rótulo é utilizado para seletores. - Cargas de trabalho sem rótulos de aplicativo: cria um rótulo padrão usando o nome da carga de trabalho e adiciona regras de propagação anti-afinidade e topologia.
- Cargas de trabalho limpas: cargas de trabalho sem afinidade ou restrições de propagação de topologia existentes recebem ambas as configurações.
- Afinidade parcial: workloads com afinidade de nó existente (mas sem antiafinidade de pod) recebem regras de antiafinidade de pod e propagação de topologia.
- Namespaces habilitados: Mutações só ocorrem em namespaces onde a proteção está habilitada.
Casos que não são modificados
O mutador de anti-afinidade e distribuição de topologia não aplica alterações nos seguintes cenários:
- Restrições de propagação de topologia existentes: cargas de trabalho que já têm restrições de propagação de topologia são totalmente ignoradas.
- Antiafinidade de pod existente: workloads com regras de antiafinidade de pod existentes, obrigatórias ou preferenciais, serão completamente ignoradas.
- Namespaces excluídos: cargas de trabalho em namespaces em que a proteção é excluída permanecem inalteradas.
- Cargas de trabalho sem nomes ou rótulos identificáveis: casos extremos em que nenhum nome de aplicativo pode ser determinado são ignorados normalmente.
Mensagens de erro de implantação de medidas de segurança
Esta seção descreve as mensagens de erro que você pode encontrar quando as Proteções de Implantação detectam configurações não compatíveis, juntamente com as correções recomendadas.
Mensagens de erro de salvaguarda geral
A tabela a seguir lista mensagens de erro para políticas gerais de Proteções de Implantação:
| Policy | Mensagem de erro | Corrigir |
|---|---|---|
| Impor investigações | Container <container_name> in your Pod <pod_name> has no livenessProbe. Required probes: readinessProbe, livenessProbe |
Adicione verificações de atividade e preparação a cada contêiner. |
| Nenhuma imagem "mais recente" | Please specify an explicit, versioned image tag such as '1.0' for container %v. Using explicit version tags is a best practice to ensure reproducibility, prevent unintended updates, and facilitate easier debugging and rollbacks. Avoid using the 'latest' tag because it can change over time without notice. |
Use uma marca de imagem explícita diferente de latest ou em branco. Por exemplo, nginx não é permitido, mas nginx:v1.0.0 é permitido. |
| Aplicar driver CSI |
Storage class <class_name> use intree provisioner kubernetes.io/azure-file is not allowed ou Storage class <class_name> use intree provisioner kubernetes.io/azure-disk is not allowed |
Use disk.csi.azure.com ou file.csi.azure.com em vez disso. Para obter mais informações, consulte Drivers CSI no AKS. |
| Solicitações de Recursos | container <container_name> has no resource requests |
Adicione solicitações de CPU e memória ao contêiner. |
| Regras de antiafinidade | Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing |
Definir podAntiAffinity ou topologySpreadConstraints na carga de trabalho. |
| Rótulos restritos | Label kubernetes.azure.com is reserved for AKS use only |
Remova o rótulo da workload. |
| Edições de nó restrito | Tainting or labeling individual nodes is not recommended. Please use Azure CLI to taint/label node pools instead |
Use a CLI do Azure para manchar ou rotular pools de nós em vez de nós individuais. |
| Contaminações restritas | Taint with key CriticalAddonsOnly is reserved for the system pool only |
Não contamine o pool de nós de usuário com CriticalAddonsOnly. |
Padrões de Segurança do Pod: Mensagens de Erro
Observação
Os Padrões de Segurança do Pod de Linha de Base agora estão ativados por padrão no AKS Automático. Os Padrões de Segurança de Pod de linha de base no AKS Automático não podem ser desativados.
As Proteções de Implantação também dão suporte à capacidade de ativar Padrões de Segurança de Pod de Linha de Base, Restritos e Privilegiados. Para garantir que suas cargas de trabalho sejam implantadas com êxito, verifique se cada manifesto está em conformidade com os requisitos de Segurança de Pod Restrito ou Linha de Base. Por padrão, o Serviço de Kubernetes do Azure usa Padrões de Segurança de Pods Privilegiados.
| Policy | Mensagem de erro | Corrigir |
|---|---|---|
| AppArmor |
AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* ou AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost |
Remova qualquer especificação de AppArmor. O Kubernetes, por padrão, aplica as configurações de AppArmor. Em hosts com suporte, o perfil RuntimeDefault AppArmor é aplicado por padrão. |
| Espaços de Nomes do Host |
Host network namespaces are disallowed: spec.hostNetwork is set to true ou Host PID namespaces are disallowed: spec.hostPID is set to true ou Host IPC namespaces are disallowed: spec.hostIPC is set to true |
Defina esses valores como false, ou remova a especificação dos campos. |
| Contêineres privilegiados | Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true |
Defina o campo apropriado securityContext.privileged como false, ou remova o campo. |
| Capabilities | A mensagem começa com Disallowed capabilities detected |
Remova a funcionalidade mostrada do manifesto do contêiner. |
| HostPath Volumes | HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images |
Remova o volume e a montagem de volume do HostPath. |
| Portas de host | HostPorts are forbidden under baseline security policy |
Remova a especificação da porta de host do contêiner ofensivo. |
| SELinux | SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t |
Defina o campo do securityContext.seLinuxOptions.type contêiner como um dos valores permitidos. |
| Tipo de montagem do /proc | ProcMount must be undefined/nil or 'Default' in spec.containers[*].securityContext.procMount |
Ajuste spec.containers[*].securityContext.procMount para Default ou deixe-o indefinido. |
| Seccomp | Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost |
Defina securityContext.seccompProfile.type no pod ou no contêiner como um dos valores permitidos. |
| Sysctls | Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted |
Remova os sysctls não permitidos. Para obter a lista específica, consulte a especificação de padrões de segurança de pod do Kubernetes. |
| Tipos de Volume (somente PSS Restrito) | Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret |
Remova os volumes que não são um dos tipos permitidos. |
| Escalonamento de Privilégios (somente PSS Restrito) | Privilege escalation must be set to false under restricted policy |
Defina spec.containers[*].securityContext.allowPrivilegeEscalation e false para cada contêiner, initContainer e ephemeralContainer. |
| Executar como Não Raiz (apenas PSS Restrito) | Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot |
Defina spec.containers[*].securityContext.runAsNonRoot para true em cada contêiner, initContainer e ephemeralContainer. |
| Executar como usuário sem privilégios de root (somente PSS restrito) | Containers must not run as root user: spec.securityContext.runAsUser is set to 0 |
Defina securityContext.runAsUser como um valor diferente de zero ou deixe-o indefinido para o nível do pod e de cada contêiner, initContainer e ephemeralContainer. |
| Seccomp (somente PSS Restrito) | Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy |
Defina securityContext.seccompProfile.type no pod ou no contêiner como um dos valores permitidos. Isso difere da linha de base porque a política restrita não permite um valor indefinido. |
| Capacidades (somente PSS Restrito) |
All containers must drop ALL capabilities under restricted policy ou Only NET_BIND_SERVICE may be added to capabilities under restricted policy |
Todos os contêineres devem descartar ALL recursos e só têm permissão para adicionar NET_BIND_SERVICE. |
Habilitar proteções de implantação
Observação
Usar o nível de Proteções de implantação Enforce significa que você está optando por bloquear e alterar as implantações. Considere como essas políticas podem funcionar com o cluster do AKS antes de habilitar Enforce.
Habilitar proteções de implantação em um cluster existente
Habilite as Proteções de Implantação em um cluster existente que tenha o complemento do Azure Policy habilitado utilizando o comando az aks safeguard create com o sinalizador --level. Caso deseje receber avisos de não conformidade, defina --level como Warn. Caso deseje negar ou alterar todas as implantações fora de conformidade, defina-o como Enforce.
az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce
Você também pode habilitar as Proteções de Implantação usando o --cluster sinalizador e especificando a ID do recurso do cluster.
az aks safeguards create --cluster <ID> --level Enforce
Se você quiser atualizar o nível de Proteções de Implantação de um cluster existente, execute o comando a seguir com o novo valor para --level.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn
Excluindo namespaces
Você também pode excluir determinados namespaces das Proteções de Implantação. Quando você exclui um namespace, a atividade nesse namespace não é afetada por avisos ou imposição de Proteções de Implantação.
Por exemplo, para excluir os namespaces ns1 e ns2usar uma lista de namespaces separada por espaço com o --excluded-ns sinalizador, conforme mostrado no exemplo a seguir:
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --excluded-ns ns1 ns2
Ativar padrões de segurança de pod
Observação
O AKS (Serviço de Kubernetes do Azure) usa Privileged Pod Security Standards por padrão. Se você quiser reverter para a configuração padrão, defina o --pss-level sinalizador como Privileged.
Para habilitar os Padrões de Segurança do Pod nas Proteções de Implantação, use o sinalizador --pss-level para selecionar um dos seguintes níveis: Baseline, Restricted ou Privileged.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>
Atualizar sua versão do Deployment Safeguard
As Proteções de Implantação seguem o esquema de controle de versão do complemento do AKS. Cada nova versão de uma Implantação de Medidas de Segurança será lançada como uma nova versão menor no AKS. Essas atualizações serão comunicadas por meio das notas de versão do GitHub do AKS e refletidas na tabela "Políticas de Proteção de Implantação" em nossa documentação.
Para saber mais sobre controle de versão e complementos do AKS, consulte a seguinte documentação: aks-component-versions e aks-versioning-for-addons.
Verificar a conformidade entre clusters
Depois de implantar o manifesto do Kubernetes, você verá avisos ou uma possível mensagem de negação em sua CLI ou terminal se o cluster não estiver em conformidade com as Proteções de Implantação, conforme mostrado nos seguintes exemplos:
Aviso
$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created
Impor
Com as mutações da Implantação de Medidas de Segurança, o nível Enforce altera os recursos do Kubernetes, quando aplicável. No entanto, os recursos do Kubernetes ainda precisam ser aprovados em todas as medidas para serem implantados com êxito. Se as políticas da medida não forem bem-sucedidas, o recurso será negado e não será implantado.
$ kubectl apply -f deployment.yaml
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
Se os recursos do Kubernetes cumprirem as proteções de mutação aplicáveis e atenderem a todos os outros requisitos de proteção, eles serão implantados com êxito, conforme mostrado no exemplo a seguir:
$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created
Verificar a conformidade entre clusters usando o painel do Azure Policy
Para verificar se as Proteções de Implantação foram aplicadas e verificar a conformidade do cluster, navegue até a página do portal do Azure para seu cluster e selecione Políticas e, em seguida, selecione ir para o Azure Policy.
Na lista de políticas e iniciativas, selecione a iniciativa associada às Proteções de Implantação. Você verá um painel mostrando o estado de conformidade no seu cluster do AKS.
Observação
Para avaliar corretamente a conformidade em seu cluster do AKS, a iniciativa do Azure Policy deve estar no escopo do grupo de recursos do cluster.
Desabilitar proteções de implantação
Para desabilitar as Proteções de Implantação no cluster, use o delete comando.
az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>
perguntas frequentes
Posso criar minhas mutações?
Não. Caso tenha uma ideia para uma medida, abra um problema no repositório GitHub do AKS e adicione [Deployment Safeguards request] ao início do título.
Posso escolher quais mutações serão incluídas na imposição?
Não. As Proteções de Implantação são tudo ou nada. Depois de ativar Alerta ou Aplica, todas as proteções estarão ativas.
Por que meu recurso de implantação foi admitido mesmo que não estivesse seguindo as melhores práticas?
As Proteções de Implantação impõem padrões de prática recomendada por meio dos controles do Azure Policy e têm políticas que são validadas em relação aos recursos do Kubernetes. Para avaliar e impor componentes de cluster, o Azure Policy estende o Gatekeeper. A imposição do gatekeeper também opera atualmente em um modelo fail-open. Como não há nenhuma garantia de que o Gatekeeper responde à nossa chamada de rede, garantimos que, nesse caso, a validação seja ignorada para que a negação não bloqueie suas implantações.
Para saber mais, confira validação da carga de trabalho no Gatekeeper.
Próximas etapas
- Saiba mais sobre as melhores práticas para operar um cluster do AKS.