Práticas recomendadas de segurança no Cloud Run para Anthos

O Cloud Run for Anthos depende do Istio para entrada. Portanto, é possível personalizar e configurar o Istio para atender às suas necessidades. Isso também significa que o Cloud Run para Anthos pode ser afetado por problemas ou vulnerabilidades conhecidos no Istio.

Esta página foi criada para ajudar a garantir que você configure o Cloud Run para Anthos usando práticas recomendadas conhecidas e que resolva todos os problemas conhecidos para evitar a exposição não intencional dos recursos a vulnerabilidades.

Outros guias de práticas recomendadas e recursos:

Vulnerabilidades conhecidas

Como configurar caminhos em AuthorizationPolicies

Vulnerabilidade de segurança:

Descrição:

Use as AuthorizationPolicies (em inglês) do Istio para controle de acesso usando os caminhos para os serviços do Cloud Run para Anthos. Devido à CVE-2021-31920, se você configurar o controle de acesso baseado em caminho (ambos em inglês), é possível ficar vulnerável a ataques de confusão de caminho.

Por exemplo, considerando um serviço em yourservice.com/admin, em que você configurou o acesso para permitir solicitações para o caminho /admin. Se você não negar explicitamente o acesso a //admin, a vulnerabilidade de caminho em AuthorizationPolicy não impedirá o acesso a solicitações que usem o caminho //admin malformado. Como o serviço pode não diferenciar entre esses caminhos, a solicitação para um caminho inválido recebe acesso não intencional.

Contexto:

O gateway de entrada padrão do Istio usado pelo Cloud Run para Anthos depende da normalização padrão do URL, usando a opção normalize_path em proxies Envoy, que segue RFC 3986 (ambos em inglês)

Infelizmente, há vários padrões de URL de solicitação conhecidos que não são normalizados pelos padrões de normalização de URL. Consulte a seção a seguir sobre como evitar a vulnerabilidade.

Mitigação:

Para ajudar a garantir que você não esteja vulnerável a ataques de confusão de caminhos hoje, é possível implementar dois métodos:

  • Opção recomendada: negar todo o acesso por padrão

    Configure o Istio para usar um padrão de negação para as políticas AuthorizationPolicy. Isso geralmente melhora a postura de segurança do cluster. A configuração de um padrão de negação de autorização nega todas as solicitações para os serviços por padrão e permite definir explicitamente todas as condições a que uma solicitação tem acesso.

    O uso desse padrão pode significar que, se você não permitir uma condição específica, determinadas solicitações serão negadas inesperadamente. Isso pode resultar em uma experiência ruim do usuário, interrupção do serviço ou falha no cumprimento do SLO ou SLA. A compensação pela definição explícita de todo o acesso é preferível em relação a um incidente de segurança devido a acesso não intencional.

    Exemplo:

    Crie uma AuthorizationPolicy para usar o padrão de negação definindo uma política allow-nothing no namespace de destino. Por exemplo, para negar todo o tráfego a todos os serviços no namespace default, você cria:

    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: default
spec:
  {}

    Para saber mais sobre como definir uma política de tipo AuthorizationPolicy, consulte Autorização do Istio para tráfego HTTP (em inglês).

  • Opção alternativa: negar explicitamente todas as variações de URL problemáticas ao serviço

    Para evitar a implementação de um padrão de negação, você precisa garantir que o serviço de back-end pode negar todos os caminhos problemáticos. Dependendo da linguagem, do framework e de outros fatores da implementação do serviço, você precisa negar explicitamente todos os caminhos de URL que o gateway de entrada do Istio não normaliza, incluindo:

    • Várias barras ou barras invertidas: //, \\
    • Sequências de escape de barras ou barras invertidas: %2F, %2f, %5C, %5c