Usar restrições da política de segurança do Anthos Service Mesh

O Policy Controller vem com uma biblioteca padrão de modelos de restrição que podem ser usados com o pacote de segurança do Anthos Service Mesh para auditar a conformidade da vulnerabilidades de segurança da malha e práticas recomendadas.

Este pacote de restrições abrange e aplica políticas nos seguintes domínios:

• O Anthos Service Mesh aplica tráfego do mTLS
• Práticas recomendadas do AuthorizationPolicy para o Anthos Service Mesh
• Aplicação da segurança de carga de trabalho do Anthos Service Mesh

Restrições do pacote de políticas do Anthos Service Mesh

Nome da restrição	Descrição da restrição	ID do controle
asm-policy-v0.0.1-asm-ingressgateway-label	Aplicar o uso do rótulo ingressgateway do Istio apenas nos pods do ingressgateway	1.1.1
asm-policy-v0.0.1-asm-sidecar-injection	Aplicar o arquivo secundário do proxy do Istio que sempre foi injetado nos pods de carga de trabalho	1.1.2
asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny	Aplicar a política de negação de autorização padrão na malha	1.2.1
asm-policy-v0.0.1-asm-authz-policy-normalization	Aplicar a normalização do AuthorizationPolicy	1.2.2
asm-policy-v0.0.1-asm-authz-policy-safe-pattern	Aplicar os padrões seguros de AuthorizationPolicy	1.2.3
asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls	Aplicar o PeerAuthentication strict mtls no nível da malha	1.3.1
asm-policy-v0.0.1-asm-peer-authn-strict-mtls	A aplicação de todos os PeerAuthentications não pode substituir mtls rígidos	1.3.2
asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers	Aplique o jwtRules outputPayloadToHeader para evitar cabeçalhos de solicitação HTTP conhecidos	1.4.1

Perfis de pacotes

No pacote de políticas de segurança do Anthos Service Mesh, é possível usar dois perfis com base no nível de rigidez. O nível de rigidez baixa tem menos restrições aplicadas, o que oferece mais flexibilidade. O alto nível de restrição tem mais restrições aplicadas, o que fornece controle de política mais seguro.

Baixo nível de rigidez

O perfil de nível de rigidez baixa tem as seguintes restrições de política:

• O rótulo istio:ingressgateway só pode ser usado por pods de gateway de entrada do Istio.

• Em AuthorizationPolicy, os campos hosts ou notHosts só podem ser usados selecionando o gateway de entrada do Istio com o rótulo istio:ingressgateway.

• Em AuthorizationPolicy, quando os campos methods ou notMethods são usados, os valores precisam ser letras maiúsculas.

• No AuthorizationPolicy, quando o campo request.headers for usado, os valores não poderão conter espaços em branco.

• Em AuthorizationPolicy, quando os campos paths ou notPaths são usados, os valores precisam ser normalizados.

Alto nível de rigidez

O alto nível de rigidez inclui todas as restrições do baixo nível de rigidez, além das seguintes restrições:

• Em todos os pods de carga de trabalho, a anotação sidecar.istio.io/inject: false não pode ser aplicada para ignorar a injeção de proxy.

• Um nível de malha AuthorizationPolicy que define uma regra de negação padrão é aplicado.

• O AuthorizationPolicy precisa seguir ALLOW-with-positive-matching ou DENY-with-negative-match.

• No AuthorizationPolicy, quando os campos hosts ou notHosts são usados, os valores precisam ser pares de <host-name> e <host-name>:*.

• Um nível de malha PeerAuthentication que define mTLS rigorosos é aplicado.

• Para todos os PeerAuthentication na malha, o modo mTLS só pode ser UNSET ou STRICT para seguir mTLS rigoroso.

Configurações do grupo

KPT setter	Descrição
strictness-level	Perfil de nível de rigidez do pacote do Anthos Service Mesh. As opções são "Baixa" ou "Alta" (padrão).

Antes de começar

1. Instale e inicialize a Google Cloud CLI, que fornece os comandos gcloud e kubectl usados nestas instruções. Se você usa o Cloud Shell, a Google Cloud CLI já vem pré-instalada.
2. Instale o Policy Controller v.1.11.2 ou mais recente no cluster com a biblioteca padrão de modelos de restrição. Você também precisa ativar a compatibilidade com restrições referenciais, já que este pacote contém restrições referenciais.
3. Confirme se o Anthos Service Mesh está instalado no cluster.

Configurar o Policy Controller com restrições referenciais

Aviso: é possível substituir suas próprias alterações. Se você já tiver um Config no namespace gatekeeper-system, inclua todas as configurações de personalização anteriores para preservar suas alterações.

1. Salve o seguinte manifesto YAML como policycontroller-config.yaml:

   apiVersion: config.gatekeeper.sh/v1alpha1
   kind: Config
   metadata:
     name: config
     namespace: "gatekeeper-system"
   spec:
     sync:
       syncOnly:
         - group: ""
           version: "v1"
           kind: "Namespace"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "AuthorizationPolicy"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "PeerAuthentication"
   

   Este manifesto configura o Policy Controller para observar tipos específicos de objetos.

2. Aplique o manifesto policycontroller-config.yaml:

   kubectl apply -f policycontroller-config.yaml
   

Audite o pacote de políticas do Anthos Service Mesh

O Policy Controller permite aplicar políticas ao cluster do Kubernetes. Para ajudar a testar suas cargas de trabalho e a conformidade delas com relação às políticas de Anthos Service Mesh descritas na tabela anterior, implante essas restrições no modo de "auditoria" para revelar violações e, mais importante, se permitir corrigir antes de aplicar no cluster do Kubernetes.

É possível aplicar essas políticas com spec.enforcementAction definido como dryrun usando kubectl, kpt ou Config Sync.

kubectl

1. (Opcional) Visualize as restrições de política com o kubectl:

   kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

2. Aplique as restrições da política com o kubectl:

   kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   A saída é esta:

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls created
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection created
   

3. Verifique se as restrições da política foram instaladas e se existem violações no cluster:

   kubectl get -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   O resultado será assim:

   NAME                                                                                                       ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization   dryrun               0
   
   NAME                                                                                                  ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern   dryrun               0
   
   NAME                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls   dryrun               0
   
   NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls   dryrun               0
   
   NAME                                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers   dryrun               0
   
   NAME                                                                                    ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection   dryrun               0
   

kpt

1. Instale e configure o kpt. O kpt é usado nestas instruções para personalizar e implantar recursos do Kubernetes.

2. Faça o download do pacote de políticas de segurança do Anthos Service Mesh no GitHub usando o kpt:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

3. Execute a função set-enforcement-action do kpt para definir a ação de aplicação das políticas como dryrun:

   kpt fn eval asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
     -- enforcementAction=dryrun
   

4. Execute a função setter kpt para definir campos específicos de políticas de segurança do Anthos Service Mesh:

   kpt fn eval asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

5. Inicialize o diretório de trabalho com o kpt, que cria um recurso para acompanhar as alterações:

   cd asm-policy-v0.0.1
   kpt live init
   

6. Aplique as restrições da política ao kpt:

   kpt live apply
   

   A saída é esta:

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-strict-mtls created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-sidecar-injection created
   7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed
   

7. Verifique se as restrições da política foram instaladas e se existem violações no cluster:

   kpt live status --output table --poll-until current
   

   O status CURRENT confirma a instalação bem-sucedida das restrições.

Config Sync

1. Instale e configure o kpt. O kpt é usado nestas instruções para personalizar e implantar recursos do Kubernetes.

Os operadores que usam o Config Sync para implantar políticas nos clusters podem usar as seguintes instruções:

1. Altere para o diretório de sincronização do Config Sync:

   cd SYNC_ROOT_DIR
   

   Observação: o Kpt v1.0.0-beta.17 e versões posteriores criam automaticamente um arquivo resourcegroup.yaml durante live init que não precisa ser verificado no repositório do Config Sync. Adicione resourcegroup.yaml ao arquivo .gitignore do repositório se ainda não estiver presente.

   Para criar ou anexar .gitignore com resourcegroup.yaml:

   echo resourcegroup.yaml >> .gitignore
   

2. Crie um diretório policies dedicado:

   mkdir -p policies
   

3. Faça o download do pacote de políticas de segurança do Anthos Service Mesh no GitHub usando o kpt:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1 policies/asm-policy-v0.0.1
   

4. Execute a função set-enforcement-action do kpt para definir a ação de aplicação das políticas como dryrun:

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
   

5. Execute a função setter kpt para definir campos específicos de políticas de segurança do Anthos Service Mesh:

   kpt fn eval policies/asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

6. (Opcional) Visualize as restrições de política a serem criadas:

   kpt live init policies/asm-policy-v0.0.1
   kpt live apply --dry-run policies/asm-policy-v0.0.1
   

   A saída é esta:

   Dry-run strategy: client
   inventory update started
   inventory update finished
   apply phase started
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny apply successful
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization apply successful
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern apply successful
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label apply successful
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls apply successful
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls apply successful
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers apply successful
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection apply successful
   apply phase finished
   inventory update started
   inventory update finished
   apply result: 8 attempted, 8 successful, 0 skipped, 0 failed
   

7. Se o diretório de sincronização do Config Sync usar Kustomize, adicione policies/asm-policy-v0.0.1 à raiz kustomization.yaml. Caso contrário, remova o arquivo policies/asm-policy-v0.0.1/kustomization.yaml:

   rm SYNC_ROOT_DIR/policies/asm-policy-v0.0.1/kustomization.yaml
   

8. Envie as alterações para o repositório do Config Sync:

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy audit enforcement'
   git push
   

9. Verifique o status da instalação:

   watch gcloud beta container fleet config-management status --project PROJECT_ID
   

   O status SYNCED confirma a instalação das políticas.

Visualizar violações de políticas

Depois que as restrições de política são instaladas no modo de auditoria, as violações no cluster podem ser visualizadas na IU usando o Painel do Controlador de políticas.

Também é possível usar kubectl para visualizar violações no cluster usando o seguinte comando:

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

Se houver violações, uma lista das mensagens de violação por restrição poderá ser visualizada com:

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'

Alterar ação de aplicação do pacote de políticas do Anthos Service Mesh

Depois de analisar as violações de políticas no cluster, considere alterar o modo de aplicação para que o controlador de admissão warn ou deny bloqueie a aplicação de recursos sem compliance no cluster.

Aviso: a ação de aplicação deny precisa ser usada com cuidado, já que ela pode bloquear as alterações necessárias, resultando na interrupção de cargas de trabalho críticas ou do cluster. É altamente recomendável que apenas as ações de aplicação warn ou dryrun sejam usadas em clusters com cargas de trabalho de produção, ao testar novas restrições ou realizar migrações, como upgrade de plataformas. Para mais informações sobre as ações de cumprimento, consulte Auditoria com restrições.

kubectl

1. Use o kubectl para definir a ação de cumprimento das políticas como warn:

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
   

2. Verifique se a ação de cumprimento das restrições da política foi atualizada:

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
   

kpt

1. Execute a função set-enforcement-action do kpt para definir a ação de aplicação das políticas como warn:

   kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

2. Aplique as restrições da política:

   kpt live apply
   

Config Sync

Os operadores que usam o Config Sync para implantar políticas nos clusters podem usar as seguintes instruções:

1. Altere para o diretório de sincronização do Config Sync:

   cd SYNC_ROOT_DIR
   

2. Execute a função set-enforcement-action do kpt para definir a ação de aplicação das políticas como warn:

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

3. Envie as alterações para o repositório do Config Sync:

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy bundle warn enforcement'
   git push
   

4. Verifique o status da instalação:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Seu repo que aparece na coluna SYNCED confirma a instalação das políticas.

Aplicação da política de testes

Crie um recurso não compatível no cluster usando o seguinte comando:

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: non-compliant-authz-policy
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["get"]
EOF

O controlador de admissão produzirá um alerta listando as violações da política que esse recurso viola, conforme mostrado no exemplo a seguir:

Warning: [asm-policy-v0.0.1-asm-authz-policy-normalization] in rules-to-operation, methods or notMethods must be uppercase
authorizationpolicy.security.istio.io/non-compliant-authz-policy created

Remover o pacote de políticas do Anthos Service Mesh

Se necessário, o pacote de políticas do Anthos Service Mesh pode ser removido do cluster.

kubectl

• Use o kubectl para remover as políticas:

  kubectl delete constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
  

kpt

• Remova as políticas:

  kpt live destroy
  

Config Sync

Os operadores que usam o Config Sync para implantar políticas nos clusters podem usar as seguintes instruções:

1. Envie as alterações para o repositório do Config Sync:

   git rm -r SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Removing Anthos Service Mesh  policies'
   git push
   

2. Verifique o status:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Seu repo que aparece na coluna SYNCED confirma a remoção das políticas.