Políticas de autorização e segurança de rede ambiente

Nesta página, mostramos como criar políticas de autorização na rede ambiente.

Pré-requisitos

Antes de concluir as etapas deste documento, você precisa atender às seguintes condições:

• Um cluster do GKE em execução com a rede ambiente do Cloud Service Mesh ativada.
• Um namespace registrado em rede ambiente (por exemplo, ambient-test) com cargas de trabalho de cliente e servidor de amostra implantadas.
• TLS mútuo (mTLS) ativado entre as cargas de trabalho do cliente e do servidor usando um GCPServerTLSPolicy (com mtlsMode: Strict) e um GCPClientTLSPolicy. As regras de GCPAuthzPolicy baseadas em identidade que correspondem a CLIENT_CERT_URI_SAN exigem o mTLS ativo para extrair a identidade SPIFFE do cliente.

Para uma configuração detalhada do ambiente, consulte Preparar a rede ambiente do GKE.

Política de negação por padrão

Por padrão, a API GKE Ambient Authorization Policy permite todo o tráfego, a menos que seja restrito por uma política, correspondendo ao comportamento padrão do Kubernetes NetworkPolicy.

A ação DENY_BY_DEFAULT permite mudar esse comportamento padrão. Quando aplicada a um namespace, essa política bloqueia todo o tráfego para cargas de trabalho nesse namespace, a menos que seja explicitamente permitido por uma política ALLOW.

Nesta página, mostramos como configurar e usar o DENY_BY_DEFAULT no Cloud Service Mesh para estabelecer uma postura de segurança por padrão para seus workloads.

Limitações

Antes de aplicar uma política de DENY_BY_DEFAULT, observe as seguintes limitações:

• Só é possível criar uma política DENY_BY_DEFAULT por namespace.
• Uma política com a ação DENY_BY_DEFAULT não pode ter regras definidas.
• Use essa ação para definir um valor de referência matchLabels: {} em todo o namespace e segmentar todos os pods. Não é possível usar DENY_BY_DEFAULT para restrições por pod.

Configurar uma política de autorização de negação por padrão

Para estabelecer um padrão de negação por padrão em um namespace e permitir seletivamente o acesso a cargas de trabalho específicas, siga estas etapas:

1. Crie e aplique um GCPAuthzPolicy com a ação definida como DENY_BY_DEFAULT ao seu namespace.

   cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: deny-by-default-authz
     namespace: ambient-test
   spec:
     action: DENY_BY_DEFAULT
     enforcementLevel: L4
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels: {}
   EOF
   

   A saída é semelhante a:

    gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
   

   Por padrão, essa política bloqueia todo o tráfego de entrada (leste-oeste e entrada) para cargas de trabalho no namespace ambient-test. Ele não restringe o tráfego de saída originado de cargas de trabalho no namespace.

2. Para permitir o tráfego de forma seletiva, crie e aplique uma política de ALLOW:

   cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: allow-client-to-server
     namespace: ambient-test
   spec:
     action: ALLOW
     enforcementLevel: L4
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels:
           app: server
     rules:
     - from:
         sources:
         - principals:
         - principalSelector: CLIENT_CERT_URI_SAN
           principal:
             type: Exact
             value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
   EOF
   

   Substitua PROJECT_ID pela ID do seu projeto.

   A propagação da política pode levar até três minutos após a aceitação do controlador. Aguarde três minutos antes de continuar.

3. Teste a conectividade do cliente com o servidor. Ela vai ser bem-sucedida porque corresponde à política ALLOW.

   kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
   

4. Teste a conectividade do servidor com ele mesmo (ou qualquer outra carga de trabalho sem uma política de permissão explícita). Ele vai falhar por causa da política DENY_BY_DEFAULT.

   kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
   

   A saída é semelhante a:

   curl: (52) Empty reply from server.
   

Logging

Quando uma solicitação é negada pela política de autorização, os registros de acesso do proxy ambiente do GKE contêm os seguintes campos no payload JSON:

• jsonPayload.error_details: definido como - rbac_access_denied_matched_policy[none]

Use a Análise de registros no console do Cloud de Confiance para ver as entradas de registro de acesso das conexões negadas. Consulte Verificar se o tráfego é autenticado e autorizado.

Políticas de segurança de saída

Para inspecionar e controlar o tráfego de saída das cargas de trabalho de rede ambiente para endpoints externos ou a Internet, é possível rotear o tráfego de saída pelo Secure Web Proxy (SWP).

Para instruções sobre como configurar recursos GCPBackend e GCPEgressRouting, consulte Encaminhar o tráfego de saída ambiente pelo Secure Web Proxy.