|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
|
Esta é uma documentação não divulgada para Admission Controller 1.34-dev. |
Proteção contra tempo limite de avaliação de políticas
|
Este recurso está disponível a partir da versão SUSE Security Admission Controller v1.5.0 para tempo limite por Servidor de Políticas e a partir da v1.29.0 para tempo limite por política. |
A proteção contra tempo limite de avaliação de políticas é um recurso de segurança das Políticas e do Servidor de Políticas. Seu objetivo é limitar a quantidade de tempo que uma avaliação de solicitação pode levar.
de finalidade
Você pode escrever Admission Controller políticas usando tanto linguagens de programação tradicionais (como Go, Rust e outras) ou usando a linguagem de consulta especial Rego. Ambas as abordagens têm méritos, portanto, um objetivo de Admission Controller é permitir que os autores de políticas escolham a melhor ferramenta para suas necessidades.
Ao usar uma linguagem tradicional Turing-completa, podem ocorrer problemas como:
-
Código lento sem otimizações
-
Operações computacionalmente intensas
O recurso de proteção contra tempo limite de avaliação de políticas encerra a avaliação de uma solicitação após um período de tempo predefinido. Isso garante que o Servidor de Políticas tenha sempre recursos computacionais disponíveis para processar solicitações recebidas.
Limitações
Atualmente, a proteção contra tempo limite de avaliação de políticas é capaz de interromper a maioria das avaliações de longa duração. Existem certos casos extremos que ainda não foram tratados.
Isso inclui invocar uma instrução sleep de dentro de uma política e interbloqueios.
Uma futura versão do Policy Server abordará esses cenários.
Por fim, o tempo limite de avaliação de políticas afeta todas as políticas hospedadas por uma instância do Policy Server. Atualmente, não há como ajustar o tempo limite de avaliação de políticas de forma individual.
Configuração
Todos os valores dos tempos limites de avaliação por política, o tempo limite de avaliação por Policy Server e os tempos limites de webhook são validados para que todos estejam dentro de valores aceitáveis entre si. Por exemplo, não é possível definir um valor de tempo limite de avaliação de política que seja maior do que o tempo limite de webhook do Kubernetes.
Por Política
A partir da versão Admission Controller v1.29.0, cada Política Admission Controller pode definir seu próprio valor de tempo limite através de seu atributo spec.timeoutEvalSeconds. Isso não deve ser confundido com spec.timeoutSeconds, usado para o tempo limite de Webhook (veja a seção [abaixo](#comparison-with-kubernetes-dynamic-admission-controller-timeout)).
O spec.timeoutEvalSeconds é granular, permitindo o ajuste do tempo limite de avaliação por política.
Essa configuração tem precedência sobre a configuração global de tempo limite de avaliação do Servidor de Políticas.
Por exemplo, para definir um tempo limite de avaliação mais longo para uma política específica:
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
annotations:
io.kubewarden.policy.category: Secrets
io.kubewarden.policy.severity: medium
name: env-variable-secrets-scanner
spec:
module: registry://ghcr.io/kubewarden/policies/env-variable-secrets-scanner:v1.0.6
settings: {}
timeoutEvalSeconds: 10 // Set evaluation timeout
mutating: false
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations: ["CREATE"]
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["replicationcontrollers"]
operations: ["CREATE", "UPDATE"]
- apiGroups: ["apps"]
apiVersions: ["v1"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
operations: ["CREATE", "UPDATE"]
- apiGroups: ["batch"]
apiVersions: ["v1"]
resources: ["jobs", "cronjobs"]
operations: ["CREATE", "UPDATE"]Por Servidor de Políticas
A partir da versão Admission Controller v1.5.0, os Servidores de Políticas vêm com uma configuração de tempo limite de avaliação, habilitada por padrão. A interrupção da avaliação de uma solicitação ocorre após 2 segundos. Essa configuração afeta todas as políticas agendadas naquele Servidor de Políticas. O tempo limite configurável por política spec.timeoutEvalSeconds tem precedência sobre essa configuração do Servidor de Políticas.
Você pode ajustar esse comportamento usando essas variáveis de ambiente:
-
KUBEWARDEN_DISABLE_TIMEOUT_PROTECTION: Isso desabilita completamente a avaliação de política. Qualquer valor atribuído desativa o recurso. -
KUBEWARDEN_POLICY_TIMEOUT: Isso define um valor de tempo limite diferente. O valor está em segundos com um valor padrão de2.
Ao usar a PolicyServer Definição de Recurso Personalizado do Kubernetes, você pode definir essas variáveis de ambiente da seguinte forma:
# A Policy Server that has policy evaluation timeout disabled
apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
name: no-policy-timeout
spec:
env:
- name: KUBEWARDEN_DISABLE_TIMEOUT_PROTECTION
value: "true"
---
# A Policy Server that has policy evaluation timeout enabled,
# with a 3 seconds timeout value
apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
name: custom-policy-timeout
spec:
env:
- name: KUBEWARDEN_POLICY_TIMEOUT
value: "3"Comparação com o tempo limite do Controlador de Admissão Dinâmico do Kubernetes
Admission Controller é uma implementação de webhook do Controlador de Admissão Dinâmico do Kubernetes.
Internamente, o servidor de API do Kubernetes faz uma solicitação HTTP para o Servidor de Políticas do Admission Controller descrevendo um evento que está prestes a acontecer. Após a solicitação HTTP, o Servidor de API do Kubernetes aguarda uma resposta. No entanto, o servidor de API do Kubernetes não espera para sempre. Após um certo período de tempo, considera que a solicitação expirou.
Citando a documentação oficial do Kubernetes:
Como os webhooks aumentam a latência das solicitações de API, eles devem ser avaliados o mais rápido possível.
timeoutSecondspermite configurar quanto tempo o servidor de API deve esperar por uma resposta de webhook antes de tratar a chamada como uma falha.Se o tempo limite expirar antes que o webhook responda, a chamada do webhook será ignorada ou a chamada da API será rejeitada com base na política de falha.
O valor do tempo limite deve estar entre 1 e 30 segundos.
O tempo limite para um webhook de admissão é de 10 segundos por padrão.
Isso significa que, independentemente do recurso de tempo limite de avaliação de política, cada solicitação de admissão do Kubernetes está sujeita a um tempo limite.
Cada Política Admission Controller pode definir seu próprio valor de tempo limite por meio do atributo timeoutSeconds dos recursos personalizados ClusterAdmissionPolicy e AdmissionPolicy.
Por padrão, o valor do tempo limite é de 10 segundos.
|
Todas as solicitações de admissão do Kubernetes feitas a um Servidor de Políticas estão sujeitas a dois tempos limites diferentes:
|
Agora você pode examinar os seguintes cenários para entender melhor as diferenças entre o tempo limite do Webhook do Kubernetes e o tempo limite de avaliação de política do Admission Controller.
O tempo limite de avaliação de política do Admission Controller está desativado.
Suponha que você tenha um Servidor de Políticas que tem o recurso de tempo limite de avaliação de política desativado, e nenhuma política agendada nele definiu seu campo spec.timeoutEvalSeconds. Este Servidor de Políticas está hospedando uma política afetada por um bug que faz com que entre em um loop infinito durante a avaliação.
O servidor de API do Kubernetes envia uma solicitação de admissão para avaliação por esta política com bug. Como resultado, a avaliação da política entra em um loop infinito. Enquanto isso, o servidor de API do Kubernetes está aguardando uma resposta.
Após 10 segundos, ocorre o tempo limite do webhook do Kubernetes, e a solicitação é tratada de acordo com a política de falha do webhook.
Agora o Servidor de Políticas tem recursos computacionais presos neste loop infinito. Com o tempo, com mais solicitações de admissão acionando a política com bug, o Servidor de Políticas fica sem recursos computacionais. Ele não consegue responder ao servidor de API do Kubernetes. Isso é equivalente a um ataque de Negação de Serviço (DOS) ao Servidor de Políticas.
O tempo limite de avaliação de política do Admission Controller está ativado.
Suponha um cenário onde o mesmo Servidor de Políticas agora tem o recurso de tempo limite de avaliação de política ativado, seja globalmente no Servidor de Políticas, ou na Política, via o campo spec.timeoutEvalSeconds, e o tempo limite de avaliação de política é de 2 segundos.
O servidor de API do Kubernetes envia uma solicitação de admissão para avaliação por esta política com bug. Como resultado, a avaliação da política entra em um loop infinito. Enquanto isso, o servidor de API do Kubernetes está aguardando uma resposta.
Após dois segundos, o recurso de tempo limite de avaliação de política do Admission Controller interrompe a avaliação da política e produz uma resposta de rejeição. A resposta contém uma mensagem explicando que a rejeição ocorreu porque a avaliação da política não foi concluída a tempo.
|
Definir o tempo limite de avaliação de política do Admission Controller para um valor tão alto quanto o tempo limite do webhook do Kubernetes não é uma boa escolha. Embora a avaliação da política ainda seja interrompida, reduzindo as chances de um ataque DOS, a resposta final de rejeição não é produzida pelo Servidor de Políticas. A rejeição vem do servidor de API do Kubernetes com o tempo limite do webhook. Como resultado, é mais difícil para os usuários e operadores do Kubernetes detectarem essas políticas lentas ou com erro. A única prova da interrupção da avaliação da política está nos logs do Servidor de Políticas e nos eventos de rastreamento. |